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ABSTRACT 

Testing  Cobol  Programs  by  Mutation 
Jeanne  M.  Hanks 
225  Pages 

Directed  by  Dr.  Richard.  A.  DeMillo 


Program  mutation  is  a  testing  technique  which  has  been 
applied  to  Fortran  programs [ABDLS ] .  This  thesis  will 
describe  the  application  of  mutation  to  the  Cobol  language 
in  an  automated  program  mutation  system.  The  thesis  will 
describe  the  development  of  a  Cobol  Mutation  System  (CMS.l), 
its  testing  using  Fortran  mutation  analysis,  and  the  subset 
of  Cobol  that  is  supported  by  CMS.l.  The  internal 
representation  selected  to  represent  the  Cobol  source 
statements  and  a  description  of  the  mutant  operators  that 
are  implemented  in  CMS.l  will  also  be  supplied. 
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INTRODUCTION 

Program  Testing 

Methods  of  assuring  program  correctness  can  be  divided 
into  two  different  approaches:  program  proving  techniques 
and  program  testing  techniques.  Program  proving  involves  a 
formal  proof  that  a  program  performs  correctly  [DLP],  This 
approach  is  currently  ineffective  because  the  proofs  are 
generally  hard  to  produce  manually  and  are  often  incorrect 
or  prove  the  wrong  result  [DLP]. 

The  goals  of  program  testing  are  to  increase  confidence 
that  a  program  will  perform  as  desired,  to  discover  errors, 
and  to  provide  some  measure  of  performance.  Various  tech¬ 
niques  have  been  proposed  to  reduce  testing  to  a  systematic 
methodology.  These  techniques  include  random  generation, 
symbolic  execution,  and  mutation  analysis. 

Random  generation  of  test  cases  is  easy  to  concep¬ 
tualize  and  to  implement  but  is  rather  inefficient  [DLS1]. 
The  number  of  test  cases  necessary  to  execute  the  'normal' 
flow  and  the  'exception'  flow  in  a  program  can  become  very 
large. 

Symbolic  execution  of  a  program  produces  better  test 
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data  than  the  random  generation  method.  Variables  are 
treated  as  algebraic  unknowns  and  constraints  are  generated 
in  terms  of  those  unknowns  to  indicate  those  restrictions 
which  data  must  satisfy  if  a  certain  path  is  to  be  executed. 
Symbolic  execution  generates  data  which  executes  every 
statement  in  the  program  and  executes  each  branch. 

Mutation  analysis  involves  generating  test  data  by  any 
means  that  is  available,  then  applying  the  technique  to  gain 
some  measure  of  confidence  of  test  "coverage".  Through  the 
mutation  process  a  set  of  test  data  is  generated  that 
increases  the  confidence  of  a  program's  correctness. 

During  mutation  a  program  is  perturbed  in  simple  ways 
which  simulate  typical  programming  errors.  This  process 
generates  a  variety  of  mutant  programs.  Given  a  set  of  test 
data  that  the  programmer  believes  tests  his  program,  the 
mutant  programs  are  distinguished  from  the  original  program 
by  their  behaviour  on  the  test  data.  Test  data  which  is 
able  to  distinguish  all  non-equivalent  mutants  of  a  program 
must  thoroughly  exercise  the  program  and,  hence,  provide 
strong  evidence  of  the  program's  correctness  [ABDLS]  . 

Cobol  Mutation 

An  automated  system  for  Cobol  Mutation  Analysis  (CMS.l) 
has  been  developed  and  implemented  at  Georgia  Tech  on  a 
PRIME  400.  CMS.l  has  been  derived  from  the  Pilot  Mutation 
System  (PIMS  or  FMS.l)  for  Fortran  program  mutations  which 
was  designed  at  Yale  University  and  has  been  implemented  at 


Yale,  Georgia  Tech  and  the  University  of  California, 
Berkeley  [BDLS] .  CMS.l  has  the  added  capability  to  handle 
I/O  which  is  not  currently  available  for  Fortran. 

CMS.l  is  an  interactive  system  that  accepts  as  input  a 
Cobol  program  and  representative  test  data,  which,  when  ap¬ 
plied  to  the  Cobol  program,  produces  reference  output  that 
the  programmer  has  verified  to  be  correct.  CMS.l  generates 
a  large  set  of  mutants  of  the  Cobol  program  and  executes 
these  interpretively .  The  resultant  outputs  are  compared  to 
the  reference  output  to  identify  (1)  deficiencies  in  the 
test  data,  or  (2)  functionally  equivalent  versions  of  the 
program  which  are  possibly  more  efficient.  Through  this 
interactive  process,  the  user  can  become  more  confident  of 
the  program's  correctness.  For  a  detailed  study  of  this 
aspect  of  mutation  see  [ABDLS,  AA] . 

CMS.l  execution  consists  of  five  main  phases:  ENTRY, 
PRE-RUN,  MUTATION,  INTERPRETATION,  and  POST-RUN.  Figure  1 
shows  interaction  with  CMS.l. 

An  input  program,  P,  is  parsed  into  an  intermediate 
code.  If  any  Cobol  syntax  errors  exist  in  P,  the  errors  are 
displayed  at  the  user's  console.  When  no  syntax  errors 
exist  and  the  intermediate  code  has  been  created,  mutant 
descriptors  for  the  program  are  generated.  Now  the  original 
program  is  executed  interpretively  on  a  set  of  test  data 
supplied  by  the  user.  The  results  for  the  test  data  are 
shown  to  the  user  who  verifies  them  as  either  acceptable  or 


Figure  1  CMS  Interaction 
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unacceptable.  The  user  then  has  the  opportunity  to  activate 
programs  of  some  or  all  mutant  types  that  have  been 
generated  for  the  original  program.  The  results  of  the 
mutant  runs  are  displayed  for  the  user. 

The  ENTRY  phase  interacts  with  the  user  and  initializes 
the  system.  The  user  gives  the  name  of  the  program  file  to 
be  tested.  The  internal  files  necessary  for  CMS.l  runs  are 
created  by  using  the  program's  file  name  and  adding  ex¬ 
tensions  to  this  name.  For  example,  the  files  which  are 
created  are: 


f ilename.MR 
filename. MS 
f ilename. LO 
filename. TD 
f ilename. TS 
f ilename . IF 


mutant  record  file 
mutant  status  file 
log  file 
test  data  file 
test  status  file 
internal  form  file 


The  ENTRY  phase  determines  if  the  CMS.l  run  is  the 
initial  run  or  a  continuation  of  a  previous  run  by  checking 
whether  these  files  exist  or  not.  Even  if  this  run  is  a 
continuation,  the  user  is  given  an  opportunity  to  restart 
the  analysis.  If  the  run  is  a  continuation  of  a  previous 
run,  then  the  files  are  loaded.  If  this  is  a  fresh  run, 
then  the  program  is  parsed  and  its  internal  files  are 
created  (MEMORY,  SYMBOL  TABLE,  CODE,  and  STATEMENT  files). 
At  this  time,  all  the  mutant  records  for  the  program  are 
created . 


The  PRE-RUN  phase  interacts  with  the  user  to  obtain 
test  cases.  These  test  cases  may  be  contained  in  files  so 
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the  user  enters  the  name  of  the  data  file  or  the  test  data 
may  be  entered  directly  into  CMS.l.  When  all  the  input  test 
data  has  been  given,  the  program  is  interpreted  on  the  data. 
A  copy  of  the  test  cases  and  the  results  are  displayed  for 
the  user.  The  user  is  then  asked  to  indicate  if  the  test 
cases  are  acceptable  or  not.  A  test  case  is  acceptable  if 
it  generates  correct  results.  Any  test  cases  which  are 
marked  as  unacceptable  are  deleted  from  consideration. 

The  MUTATION  phase  gains  control  at  this  point.  The 
user  is  given  a  list  of  the  mutant  types,  for  example  scalar 
for  scalar  replacement,  relational  operator  replacement, 
etc.,  that  can  be  considered  and  asked  which  one  he  would 
like  to  activate.  Once  the  mutant  programs  have  been  ac¬ 
tivated,  they  are  executed  interpretively  on  the  test  data 
that  has  been  supplied.  When  mutants  are  being  executed  rn 
a  test  case,  only  those  mutants  that  affect  a  statement 
which  is  executed  by  the  test  case  are  interpreted.  For  an 
explanation  of  the  mutants  that  are  implemented  in  CMS.l, 
see  the  discussion  on  the  MUTANT  RECORD  file. 

The  INTERPRETATION  phase  is  invoked  by  the  PRE-RUN 
phase  to  execute  the  original  program  on  a  set  of  test  data 
with  execution  returning  to  the  PRE-RUN  phase.  The 
INTERPRETATION  phase  is  also  invoked  in  a  loop  by  the  MUTA¬ 
TION  phase  for  interpreting  the  mutants  and  obtaining 
results  of  the  mutants. 

The  interpreter  uses  a  program  counter,  PC,  to  control 


flow  through  the  STATEMENT  table.  Some  error  checking  is 
done  by  the  interpreter;  the  errors  that  can  be  caught  and 
their  associated  error  codes  are: 

1  TRAP,  execution  beyond  end-of-code,  or  SIZE  ERROR 
without  an  exception  handler. 

2  TIMEOUT 

more  statements  have  been  executed  than  is  allowed. 

3  DATA  FAULT 

incorrect  mixing  of  numeric  and  alphanumeric  data. 

4  UNDEFINED 

attempt  to  reference  an  undefined  data  item. 

5  I/O  FAULT  IN  OPEN/CLOSE 

attempt  to  open  a  file  that  is  already  opened  or 
attempt  to  close  a  file  that  is  not  opened. 

6  ATTEMPT  TO  READ  PAST  EOF 

7  OVERWRITE  OR  OVERREAD,  COMPARED  TO  ORIGINAL  PROGRAM 
this  error  is  detected  when  a  mutant  program  tries 
to  read  or  write  more  data  than  the  original  program 
d  id . 

8  OUTPUT  FILE  TOO  LARGE  TO  FIT  IN  BUFFER 

the  programs  output  exceeds  the  limits  of  the  CMS.l 
system. 

9  ARRAY  ELEMENT  OUT  OF  BOUNDS 

10  INCORRECT  OUTPUT 

output  of  mutant  program  differs  from  that  of  the 
original  test  program. 

11  ILLEGAL  CODE  IN  INTERNAL  FORM 

incorrect  internal  code  has  been  generated  by  the 
system. 

A  variable  is  used  to  communicate  errors  to  the  PRE-RUN 
phase  and  the  MUTATION  phase. 

When  the  interpreter  executes  a  mutant,  the  results  are 
compared  with  the  original  program  output  as  it  is  generated 
(i.e.,  when  a  write  statement  is  executed).  If  the  two  out¬ 
puts  are  not  the  same,  then  interpretation  is  halted  and  an 
error  code  is  reported  to  the  MUTATION  phase  so  that  mutant 
will  be  marked  as  'killed'.  The  main  structure  of  the 
interpreter  is  based  on  a  Fortran  COMPUTED  GO  TO  statement. 
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For  a  detailed  discussion  of  the  interpreter,  see  the 
documentation  for  SUBROUTINE  INTERP. 

After  all  the  mutant  programs  have  been  executed,  the 
results  are  displayed  for  the  user  during  the  POST-RUN 
phase.  The  user  may  see  the  live  mutants,  mark  mutants  as 
equivalent,  turn  previously  marked  equivalent  mutants  back 
on,  stop  the  run,  or  loop  back  to  the  beginning  of  the  run 
where  more  test  cases  may  be  entered. 

If  the  mutants  are  to  be  seen,  it  is  necessary  to  first 
'decompile'  the  internal  code  for  the  statement  into  a 
recognizable  Cobol  statement.  This  'decompiling'  is  accom¬ 
plished  by  examining  the  internal  form  for  a  source 
statement  and  reconstructing  its  structure  using  the  HASH 
TABLE  for  the  printable  names  of  variables. 

Plan  of  Presentation 

The  purpose  of  this  thesis  is  not  to  justify  mutation 
analysis  as  a  testing  tool  but  to  describe  the  implementa¬ 
tion  of  a  mutation  system  for  Cobol.  The  Cobol  system  is 
written  in  Fortran  and  several  major  routines  have  been 
tested  on  the  Fortran  mutation  system.  A  detailed  discus¬ 
sion  of  the  Cobol  Mutation  System  (CMS.l)  is  given  in  Chap¬ 
ter  II  which  includes  a  description  of  the  subset  of  the 
Cobol  language  supported  by  CMS.l,  a  description  of  the  file 
structures,  and  a  description  of  the  mutant  oper-tors  im¬ 
plemented  in  CMS.l.  Chapter  III  contains  a  sample  run  on 
the  CMS.l  system  and  a  discussion  of  testing  CMS.l  routines 
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on  the  Fortran  mutation  system,  FMS.2.  The  conclusion  is  in 
Chapter  IV  which  contains  suggestions  for  improving  the 
Cobol  mutation  system.  Appendix  A  contains  a  Cobol  tutorial 
of  the  Cobol  subset  suppported  by  CMS.l  and  Appendix  B 
contains  detailed  documentation  on  each  routine  in  the  CMS.l 
system. 
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CHAPTER  II 

COBOL  MUTATION  SYSTEM  (CMS.l) 

Cobol  Subset  and  Intermediate  Code 
The  level  of  Cobol  which  can  be  accepted  by  CMS.l  is 
referred  to  as  level  1  Cobol.  The  Cobol  source  program  must 
be  in  the  standard  Cobol  format  with  columns  1-6  containing 
the  sequence  number  (which  is  ignored  by  CMS.l);  column  7  is 
either  blank  or  contains  a  hyphen  for  the  continuation  of  a 
non-numeric  literal  or  contains  an  asterisk  for  a  comment 
line;  information  beyond  column  72  is  ignored  [A],  A  list 
of  acceptable  Cobol  verbs  follows.  For  each  verb  the  format 
for  the  internal  form  generated  by  the  parser  for  use  by  the 
interpreter  is  given.  A  detailed  Cobol  tutorial  is  given  in 
Appendix  A. 


MOVE 

MOVE  {data  name-1  |  literal}  TO  data-name-2 
[data-name-3  ]  . .  . 

The  internal  form: 

<MOVXn><sourceXdest-l>. .  .<dest-n> 

ADD 

ADD  {data-1  I  literal-1}  [data-2  |  literal-2]  ...  TO 


data-m  [ROUNDED]  (ON  SIZE  ERROR  imperative-statement] 
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The  internal  form: 

<ADDXrndXsizeXnXop-l>. .  .<op-n> 

The  rnd  field  specifies  whether  to  round  the  result  or 
not.  The  size  field  indicates  if  a  size  error  clause  was 
given  or  not. 

ADD  GIVING 

ADD  {data-1  |  literal-1}  {data-2  I  literal-2) 

[data- 3  I  literal-3]...  GIVING  data-m  [ROUNDED] 

[ON  SIZE  ERROR  imperative  statement] 

The  internal  form: 

<ADGXrndXsi zeXnXop-l>. .  .<op-nXdest> 

SUBTRACT 

SUBTRACT  [data-1  I  literal-1}  [data-2  I  literal-2] . . . 
FROM  data-m  [  ROUNDED  ]  [ON  SIZE  ERROR  imperative 
statement] 

The  internal  form: 

<SUXrndXsi  zeXnXop-l>. .  .<op-n> 

SUBTRACT  GIVING 

SUBTRACT  {data-1  I  literal-1}  [data-2  |  literal-2]... 
FROM  {data-m  I  literal-m}  GIVING  data-n  [  ROUNDED  ] 

[ON  SIZE  ERROR  imperative-statement] 

The  internal  form: 

<SUGXrndXsi  zeXnXop-l>. .  ,<op-n><dest> 


t 
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MULTIPLY 

MULTIPLY  {data-1  |  literal-1}  BY  data-2  [  ROUNDED  ] 

[ON  SIZE  ERROR  imperative  statement] 

The  internal  form: 

<MULXrndXsi  zeXop-lXop-2> 

MULTIPLY  GIVING 

MULTIPLY  {data-1  |  literal-1}  BY  {data-2  |  literal-2} 
GIVING  data- 3  [  ROUNDED  ]  [ON  SIZE  ERROR 
imperative-statement} 

The  internal  form: 

<MUGXrndXsizeXop-lXop-2Xdest> 

DIVIDE 

DIVIDE  {data-1  I  literal-1 }  INTO  data-2  [  ROUNDED  ] 

[ON  SIZE  ERROR  imperative-statement] 

The  internal  form: 

<DIVXrndXsi  zeXop-lXop-2> 

DIVIDE  GIVING 

DIVIDE  {data-1  |  literal-1}  {  INTO  |  BY  } 

{data-2  I  literal-2}  GIVING  data-3  [  ROUNDED  ] 

[ON  SIZE  ERROR  imperative-statement] 

The  internal  form: 

<DIVXrndXsi  zeXop-lXop-2Xdest> 

For  the  internal  form,  the  parser  codes  both  the  BY  and 
INTO  options  in  the  form  of  the  INTO.  CMS.l  will  accept 
both  forms  of  the  DIVIDE  GIVING  statement. 
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COMPUTE 

COMPUTE  data-1  [  ROUNDED  ]  =  {data-2  | 
literal-1  |  arithmetic-expression} 

[ON  SIZE  ERROR  imperative-statement] 

The  internal  form: 

<COMXrndXsi  zeXidentXarithmetic  expression> 

Where  ident  refers  to  the  data  item  that  receives  the 
result  of  the  compute. 


GO  TO 

GO  TO  procedure-name 
The  internal  form: 

<GOXprocedure> 

GO  TO  ...  DEPENDING 

GO  TO  procedure-name-1  [procedure-name-2]... 
DEPENDING  on  data-name 
The  internal  form: 

<GODXnXidentXproc-l>. .  .<proc-n> 

PERFORM 

PERFORM  procedure-name-1  [  THRU  procedure-name-2] 
The  internal  form 
<PEVXproc-l  ><proc-2> 
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PERFORM-VARYING 

PERFORM  procedure-name-1  [  THRU  procedure-name-2] 
VARYING  data-name-1  FROM  {literal-2  |  data-name-2] 

BY  {literal-3  |  data-name-3}  UNTIL  condition-1 
The  internal  form: 

<PEVXproc-lXproc-2><  id>  <low>  <high><inc> 

<REPlXlowXh  ighX  incXstar  t><stop> 

The  REP1  operation  for  the  internal  form  of  a  PERFORM 
VARYING  statement  is  an  internal  operation  to  aid  in  the 
repeating  of  the  procedures.  After  the  procedures  are 
executed  the  control  passes  to  this  statement  where  the  con¬ 
dition  can  be  tested  for  its  truth  to  determine  if  the 
procedures  should  be  executed  again  or  if  the  PERFORM  VARY¬ 
ING  is  to  be  terminated. 

PERFORM  TIMES 

PERFORM  procedure-narae-1  [  THRU  procedure-name-2] 
{data-name-1  I  integer-1]  TIMES 
The  internal  form: 

<PETXproc-lXproc-2X  ident> 

<REP2XcountXstartXstop> 

As  in  the  PERFORM  VARYING,  it  was  necessary  to  im¬ 
plement  another  internal  operation  for  the  PERFORM  TIMES  to 
determine  how  many  times  the  procedures  have  been  executed. 
The  count  field  is  decremented  each  time  the  procedures  are 
executed  until  it  is  zero  and  the  PERFORM  TIMES  is  com- 


pletely  executed.  The  start  field  is  a  pointer  to  the  first 
statement  in  the  procedures  being  PERFORMed  and  the  stop 
field  contains  the  statement  number  of  the  last  statement 
being  PERFORMed. 

PERFORM  UNTIL 

PERFORM  procedure-name-1  [  THRU  procedure-name-2] 

UNTIL  condition-1 
The  internal  form: 

<PEUXproc-l  ><proc-2Xlog  ical  expression> 

IF 

IF  condition  {statement-1  I  NEXT  SENTENCE  } 

[{  ELSE  }  {statement-2  |  NEXT  SENTENCE  }] 

The  internal  form: 

CIFXELSE-statement  pointerXlogical  expression> 

OPEN 

OPEN  INPUT  [file-name]  ... 

OPEN  OUTPUT  [file-name]  ... 

The  internal  form: 

<OPEN> <1  |  2  I  ...  |  20 > 

Where  1  thru  10  reference  one  of  the  ten  input  files 
and  11  thru  20  reference  one  of  the  ten  output  files. 


CLOSE 

CLOSE  file-name-1  [filename-2]  ... 

The  internal  format: 

CCLOSEX1  I  2  |  ...  I  20> 

READ 

READ  file-name  RECORD  [  INTO  data-name] 
AT  END  imperative-statement 
The  internal  form: 

<READ><1  |  2  |  ...  I  10><into-ident> 


WRITE 

WRITE  record-name  [  FROM  data-name] 

The  internal  form  of  this  statement  is: 

<WRITEX1 1  |  12  |  ...  I  20><  from- i  den  t><  ad  vane  e> 


STOP 

STOP  RUN 

The  internal  form: 

<STOP> 

There  are  two  operations  that  are  coded  by  the  parser 
for  use  in  the  CMS.l  system.  These  two  operations  are  not 
supported  in  the  Cobol  subset  and  will  not  be  compiled  by 
the  parser.  These  two  operations  are  the  RETURN  and  the  NO- 
OP.  These  operations  are  needed  to  implement  the  PERFORM 


verbs;  when  executing  a  PERFORM,  it  is  necessary  to  return 
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program  control  to  the  statement  following  the  PERFORM 
statement  after  the  last  statement  of  the  paragraph  range 
has  been  executed.  To  make  this  feasible,  the  parser 
inserts  a  NO-OP  at  the  end  of  each  paragraph  and  the 
interpreter  changes  the  NO-OP  into  a  RETURN,  if  a  PERFORM  is 
being  executed. 


File  Structures 

There  are  several  files  the  system  produces  in  order  to 
store  information  from  one  run  to  the  next.  These  are  shown 
in  Figure  2,  which  also  outlines  the  major  functions  of  each 
phase.  The  major  functions  are: 

The  internal  form  file  stores  the  parsed  version 
of  the  program. 

The  test  data  file  stores  for  each  test  case,  the 
test  data  input  and  the  results  of  execution  of  that 
test  data. 

The  mutants  information  file  keeps  the  mutant 
descriptor  records  plus  various  other  counts  on 
what  types  of  mutants  have  been  produced. 

For  a  more  detailed  discussion  see  [BDLS ] . 

INTERNAL  REPRESENTATION 

The  'INTERNAL  FORM'  of  a  program  consists  of  the 
STATEMENT  table,  CODE  array,  SYMBOL  TABLE,  MEMORY  array,  and 
HASH  TABLE.  The  INTERNAL  FORM  file  contains,  in  addition  to 


Figure  2  CMS  File  Layout 
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these  files,  the  sizes  for  each  of  the  files.  These  sizes 
are  stored  in  the  beginning  of  the  INTERNAL  FORM  file;  fol¬ 
lowed  by  the  STATEMENT,  CODE,  SYMBOL,  MEMORY,  and  HASH 
files.  The  INTERNAL  FORM  files  are  created  when  the  program 
is  parsed.  Due  to  the  nature  of  the  CMS.l  system  there  are 
several  levels  of  indirection  which  have  been  incorporated 
in  order  to  maintain  all  the  information  that  is  necessary 
for  mutation. 

Every  entry  in  the  STATEMENT  table  references  its  code 
in  the  CODE  array  which  contains  references  to  the  SYMBOL 
TABLE  for  variables,  literals,  paragraph-names,  etc.  and 
finally  the  SYMBOL  TABLE  contains  references  to  memory 
locations  for  variables  and  literals  in  the  literal  pool 
contained  in  low  memory.  The  SYMBOL  TABLE  also  contains 
references  to  the  HASH  TABLE  for  a  variable's  name;  this  is 
usually  used  for  'decompiling'  a  statement. 


STATEMENT  TABLE  FILE 


The 

STATEMENT 

table  contains 

an  entry 

for 

each 

executable 

statement 

contained  in  the 

program. 

The 

file 

contains  records  of  three  elements  each  with  the  following 
format ; 


Position  Use 


1  -  reference  to  the  code  array  for  the  statement 


2  -  line  number  of  the  associated  source  listing 

3  -  statement  level 

0  -  continuation  of  a  statement 

1  -  beginning  a  new  statement 

2  -  n  -  depth  in  a  conditional  statement 

CODE  ARRAY 

The  CODE  file  is  a  sequential  array  that  contains  the 
intermediate  code  for  each  Cobol  statement;  it  also  contains 
an  element  giving  the  length  of  the  code  for  a  statement. 
The  length  of  each  Cobol  statement  varies  depending  on  the 
operation  and  the  length  can  even  vary  for  the  same  type  of 
operation . 

This  organization  of  the  CODE  array  allows  for  easy  im¬ 
plementation  of  mutant  descriptors.  It  is  not  necessary  to 
alter  the  internal  code  for  the  original  source  statement 
because  the  internal  code  for  the  mutated  statement  can  be 
appended  to  the  end  of  the  code  array.  The  statement  table 
entry  for  the  code  reference  can  be  changed  to  reference  the 
mutated  statement.  Cleaning  up  after  a  mutant  program  is 
executed  is  accomplished  by  changing  the  statement  table 
reference  back  to  the  internal  form  of  the  source  statement. 

SYMBOL  TABLE 

The  SYMBOL  TABLE  has  been  designed  to  contain  important 
information  that  must  be  obtained  at  run  time.  It  is  thus 
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necessary  for  the  SYMBOL  TABLE  to  be  resident  in  core  during 
execution . 

The  first  record  in  the  SYMBOL  TABLE  is  for  the  name  of 
the  Cobol  program.  The  next  20  records  are  reserved  for  the 
INPUT  and  OUTPUT  files  that  can  be  used  in  the  Cobol  program 
(CMS.l  allows  up  to  10  input  files  and  10  output  files). 
The  reserved  words  ZERO  and  BLANK  are  used  so  widely  in  most 
Cobol  programs  that  we  have  included  these  variables 
automatically  in  the  SYMBOL  TABLE  and  in  MEMORY.  The  rest 
of  the  SYMBOL  TABLE  is  created  by  the  parser.  Items  are 
entered  into  the  SYMBOL  TABLE  as  they  are  encountered  in  the 
program.  The  HASH  TABLE  is  used  to  determine  if  a  data  item 
has  been  entered  previously  or  not.  All  the  data  items 
defined  in  a  Cobol  DATA  DIVISION  are  entered  in  the  same  or¬ 
der  as  they  are  encountered.  After  the  DATA  DIVISION  is 
parsed,  the  PROCEDURE  DIVISION  is  parsed  and  the  PARAGRAPH- 
NAMES  and  literals  are  entered  into  the  SYMBOL  TABLE.  The 
SYMBOL  TABLE  file  is  an  array  containing  10  elements  with 
the  following  information  for  each  record: 

Position  Use 

1  -  pointer  to  the  hash  table  for  the  printable  name, 

this  is  used  for  'decompiling'  a  statement. 

2  -  type 

1  -  unsigned  numeric 

2  -  signed  numeric 

3  -  alphanumeric 

4  -  edited 

5  -  group  item 

6  -  continuation  of  a  table  item 

7  -  numeric  literal 
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8  -  alphanumeric  literal 

9  -  paragraph  name 

3  -  level  number,  or 

beginning  statement  number  if  this  is  a  paragraph 
name  entry 

4  -  number  of  digits  for  a  numeric  item,  or, 

memory  location  for  a  PICTURE  item,  or, 
ending  statement  number  if  this  is  a  paragraph 
name  entry,  or 

multiplier  for  the  first  subscript  if  this  is 
a  table  item  entry 

5  -  memory  location,  or 

multiplier  for  the  second  subscript  if  this  is 
a  table  item  entry 

6  -  length  of  the  item  in  memory,  or 

maximum  allowed  subscript  for  the  first  subscript 
if  this  is  a  table  item  entry 

7  -  table  level 

0  -  scalar 

1  -  one  level  table,  row  item 

2  -  two  level  table 

or,  the  maximum  allowed  subscript  for  the  second 
subscript  if  this  is  the  second  row  of  informa¬ 
tion  table  item  entry 

8  -  pointer  to  the  value  string  in  the  literal  pool, 

if  a  VALUE  clause  was  specified,  or 

the  number  of  occurrences  in  the  second  row  for  a 

table  item  entry 

9  -  SYMBOL  TABLE  entry  for  a  redefined  item 

10  -  Number  of  the  source  statement  for  the  data-item 
entry. 


MEMORY 

The  MEMORY  array  contains  the  Cobol  source  program's 
memory  and  the  storage  areas  necessary  to  execute  a  Cobol 
program.  MEMORY  is  a  sequential  single-dimension  array. 
The  first  thirty  elements  are  reserved  for  the  interpreter's 
working  storage.  The  literal  pool  follows  the  working 


storage.  This  literal  pool  contains  the  PICTURE 
specifications  for  the  edited  data  items,  constants  used  in 
the  Cobol  VALUE  clauses,  and  any  literal  constants  used  in 
the  program.  The  Cobol  variables  ZERO  and  BLANK  are  the 
first  two  items  in  the  literal  pool.  A  variable  is  kept  in 
COMMON  to  contain  the  location  of  the  end  of  the  literal 
pool.  The  working  memory  follows  the  literal  pool  and 
consists  of  character  data.  PICTURE  items  are  the  only 
items  that  do  not  have  all  their  auxilliary  information 
contained  in  the  SYMBOL  TABLE  because  they  need  more  in¬ 
formation  than  can  be  contained  in  one  record;  therefore, 
three  extra  words  are  stored  in  memory  with  a  PICTURE’S 
description.  The  structure  of  a  picture  item  follows: 

Position  Use 

1  -  Picture  length 

2  -  Number  of  digits  in  the  picture 

3  -  Number  of  decimal  digits  in  the  picture 

4  -  The  actual  picture  description 

HASH  TABLE 

The  HASH  TABLE  is  used  to  hold  the  printable  names  of 
Cobol  reserved  words,  program  file  names,  and  variables. 
The  HASH  TABLE  contains  the  names  for  all  the  RESERVED 
words,  the  Cobol  program  name,  the  Cobol  input  and  output 
file  names,  the  variables,  and  the  paragraph  names.  Each 
record  in  this  file  contains  17  words.  The  first  15  words 
are  used  to  store  the  name  with  2  characters  per  word;  Cobol 
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allows  a  maximum  of  30  characters  per  name.  The  16th  word 
contains  the  number  of  characters  actually  used  in  the  name 
and  the  17th  word  is  the  location  in  the  SYMBOL  TABLE  for 
this  item.  The  record  layout  is  as  follows: 

Position  Use 

1  thru  15  -  Print  name  with  two  characters  per  word. 

16  -  Number  of  characters  in  the  print  name. 

17  -  SYMBOL  TABLE  location  for  the  item. 

TEST  STATUS  FILE 

The  TEST  STATUS  file  contains  status  information  for 
each  test  case  that  is  accepted  for  CMS.l.  Each  record  of 
the  file  contains  42  words  of  information.  The  first  record 
of  the  file  indicates  which  of  the  twenty  allowable  Cobol 
files  are  used,  how  many  test  cases  have  been  defined,  how 
many  test  cases  have  been  defined  during  the  current  run, 
and  the  next  available  location  in  the  file  for  appending 
information  for  the  next  test  case  to  be  defined.  Note  that 
INPUTO  is  the  first  Cobol  input  file  and  that  INPUT9  is  the 
tenth  input  file  and  similarly  for  the  output  files.  The 
format  of  the  first  record  in  the  TEST  STATUS  file  is  as 
follows : 

Position  Use 

1  -  Indicates  if  INPUTO  has  been  used  or  not. 

0  -  not  used 
1  -  used 

2  -  Indicates  if  INPUT1  has  been  used  or  not. 

0  -  not  used 
1  -  used 
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3-20  -  Similar  to  the  above  for  INPUT2  thru  INPUT9 
and  for  OUTPUTO  thru  0UTPUT9. 

21  -  Total  number  of  test  cases. 

22  -  The  number  of  test  cases  previously  defined. 

23  -  Location  of  the  next  available  record  in  this 

file  for  appending  information  for  a  new  test 
case . 

After  the  first  record  for  file  information,  there  are 
two  records  for  each  test  case.  The  first  contains  informa¬ 
tion  about  the  number  of  records  in  each  Cobol  input  and 
output  file  and  the  starting  position  for  the  file  in  the 
TEST  DATA  file.  The  format  of  the  TEST  STATUS  file  is: 

Position  Use 

1  -  The  starting  position  in  the  TEST  DATA  file  for 

INPUT  0. 

2  -  The  number  of  records  in  INPUTO. 

3  -  The  starting  position  in  the  TEST  DATA  file  for 

INPUT1 . 

4  -  The  number  of  records  in  INPUT1. 

5-40  -  Similar  to  the  above  for  the  other  INPUT  and  OUTPUT 

files. 

41  -  The  number  of  statements  in  the  original  program 
that  are  executed  by  this  test  case. 

The  second  record  for  a  test  case  is  a  bit  map  which 
indicates  which  statements  are  executed  by  the  test  case. 
The  first  bit  of  each  word  is  not  used  so  there  are  15 
usable  bits  per  word.  There  are  42  records  which  give  a 
maximum  of  42  x  15  =  630  bits  per  record. 


For  Cobol 
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programs  with  more  than  630  procedure  division  statements, 
either  the  record  size  for  the  TEST  STATUS  file  will  have  to 
be  increased  or  more  than  2  records  per  test  case  will  have 
to  be  used. 

TEST  DATA  file 

The  TEST  DATA  file  is  a  sequential  file  that  contains 
the  input  and  output  for  each  test  case.  The  Cobol  input 
for  all  the  input  files  used  by  the  original  source  program 
is  stored  in  sequential  order  in  the  TEST  DATA  file  followed 
by  the  output  files  generated  by  the  original  source  program 
for  a  test  case.  The  information  for  additional  test  cases 
is  stored  in  the  same  manner  following  the  existing  data. 
The  data  is  stored  in  a  packed  format  by  SUBROUTINE  PACK. 
This  packed  format  contains  a  character  followed  by  a  count 
of  how  many  exist  together;  if  a  character  is  not  repeated 
in  the  file,  then  it  has  no  repeat  count  associated  with  it. 
An  initial  segment  of  the  ASCII  codes  represent  unprintable 
characters.  Values  in  this  initial  segment  are  treated  as 
repeat  counts.  The  subroutine  PACK  breaks  up  long  repeat 
strings  in  order  to  keep  repeat  counts  within  bounds. 
(Note:  For  portability,  EBCDIC  also  has  an  initial  segment 
of  nonprintable  characters) .  The  reason  this  packing  is 
done  with  repeat  counts  is  to  save  storage  space.  The 
character  and  its  count  are  stored  in  half-words  of  one  byte 
each . 
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MUTANT  STATUS  FILE 

The  MUTANT  STATUS  file  is  created  by  appending  .MS  to 
the  filename  of  the  program  being  tested.  This  file 
contains  status  information  about  the  mutants  concerning  the 
mutant  types  that  have  been  turned  on;  the  number  of  mutants 
created  for  each  mutant  type;  a  pointer  for  each  mutant  type 
to  the  first  record  in  the  MUTANT  RECORD  file;  the  number  of 
'live*  and  'dead*  mutants;  and  the  number  of  mutants  that 
are  'killed'  by  each  of  the  eleven  errors  detected  by  the 
interpreter . 

The  first  record  on  the  MUTANT  STATUS  file  contains  a 
count  of  the  total  number  of  mutants  created.  This  count  is 
in  the  first  word  of  the  16  word  record.  The  next  several 
records  contain  header  information  for  each  mutant  type. 
The  header  uses  four  words  to  store  its  information;  the 
header  format  is: 

Psition  Use 

1  -  Mutant  type. 

2  -  On  or  off 

0  -  off 

1  -  on 

3  -  On  or  off  this  run 

0  -  off 

1  -  on 

4  -  Location  in  the  MUTANT  STATUS  file  for  the 

status  block. 

The  MUTANT  STATUS  file  has  16  words  per  record.  This 
means  that  four  headers  can  be  placed  in  one  record;  since 
there  are  currently  25  mutant  types,  5  records  are  needed  to 
store  the  header  information.  The  information  contained  in 


the  header  blocks  is  resident  in  core  during  the  CMS.l  run. 

For  each  mutant  type  there  is  one  record  that  contains 
the  mutant  status  information.  The  information  and  the 
format  for  a  mutant  status  record  is: 

Position  Use 

1  -  Number  of  mutants  for  this  type. 

2  -  Number  of  words  for  the  bit  map. 

3  -  MUTANT  RECORD  file  location  for  the  first  mutant 

record  of  this  type. 

4  -  Number  of  live  mutants. 

5  -  Number  of  dead  mutants. 

6  -  Number  killed  by  trap,  attempt  to  execute  beyond 

the  end  of  code  by  the  STOP  statement  being  deleted 
or  no  SIZE  ERROR  clause  given  and  a  size  error 
occurs . 

7  -  Number  killed  by  time-out. 

8  -  Number  killed  by  data  fault. 

9  -  Number  killed  by  initialization  fault. 

10  -  Number  killed  by  I/O  fault  in  OPEN  or  CLOSE. 

11  -  Number  killed  by  attempt  to  read  past  end-of-file. 

12  -  Number  killed  by  writing  more  than  original  program 

13  -  Number  killed  by  output  too  large  for  the  buffer. 

14  -  Number  killed  by  array  subscripts  out-of-bounds. 

15  -  Number  killed  by  incorrect  output. 

16  -  Number  killed  by  garbage  in  the  CODE  array. 

Following  these  records  are  the  bit  maps  for  the  live, 

dead,  and  equivalent  mutants,  where  there  is  one  bit  for 
each  mutant.  In  all  of  the  bit  maps  the  first  bit  (sign 
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bit)  of  each  word  is  not  used.  The  bit  maps  are  of  varying 
length  depending  on  the  program  and  on  the  mutant  operators. 
The  number  of  records  needed  for  a  bit  map  is  rounded  up  to 
the  nearest  whole-record  size.  There  are  four  words  per 
record  with  15  usable  bits  per  word,  thus,  there  are  60  bits 
per  record  and  the  number  of  records  necessary  to  store  a 
bit  map  is  the  next  largest  integer  greater  than  the  number 
of  mutant  divided  by  60  bits  per  record. 


MUTATION  RECORD  FILE 

The  particular  mutant  types  that  have  been  implemented 
in  CMS . 1  are  data,  input/output,  control  structure,  and 
procedural  mutations.  Data  mutations  alter  the  data 
descriptions  contained  in  the  SYMBOL  TABLE.  INPUT/OUTPUT 
mutations  deal  with  changing  a  file  reference  in  one  read  or 
write  statement.  For  example,  an  input  file  may  be  ex¬ 
changed  for  another  input  file  in  a  read  statement,  or  an 
output  file  exchanged  with  another  output  file  in  a  write 
statement;  but  an  input  may  not  be  exchanged  with  an  output. 
Control  structure  mutations  alter  statements  that  deal  with 
program  flow.  Procedural  mutations  are  those  mutations 
which  are  applied  to  procedure  division  statements. 

The  mutant  record  file  consists  of  n  records,  where  n 
is  the  number  of  mutants  created  for  the  program.  Each 
record  is  4  integers  long.  All  the  mutant  descriptors  for  a 
mutant  type  are  stored  contiguously  in  the  mutant  record 
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file.  The  first  word  is  the  mutant  type  and  the  other  three 
contain  information  for  that  mutant  type.  A  mutant  record 
exists  for  each  mutant  that  can  be  applied  to  a  program. 
The  following  is  a  list  of  the  mutants  and  their  descriptor 
records  (an  x  in  any  field  means  that  that  field  is  not 
used).  All  mutants  that  alter  a  statement  are  copied  at  the 
end  of  the  code  array  and  the  code  reference  in  the 
statement  table  is  changed  to  refer  to  this  mutant 
statement.  To  restore  the  internal  form  after  implementing 
a  statement  mutant  we  only  need  to  change  the  statement 
table  code  reference  to  refer  back  to  the  original 
statement.  Data  mutations  alter  the  data  descriptions  to 
the  original  statement.  The  following  is  an  explanation  of 
the  mutant  types  that  are  implemented  in  CMS.l. 

1  Decimal  alterations  move  implied  decimal  in  numeric  items 

one  place  to  the  left  or  right,  if  possible. 

<DECXSYMBOL  TABLE  locationX+1  I  -1><X> 

Where  +1  -  add  1  digit  to  the  fraction  part, 

-1  -  subtract  1  digit  from  the  fraction  part. 

2  Reverse  occurs  clauses  reverses  the  row  and  column  size  in 

a  two-level  table. 

<REVERSE-OCCURSXS YMBOL  TABLE  location><x> 

<SYMB0L  TABLE  2> 

3  Alter  occurs  clause  changes  the  dimension  of  a  one-  or 

two-level  table  by  adding  or  subtracting  1  from  the 


d  imension. 


<ALTER-OCC URS> <SYMBOL  TABLE  location><code><x> 
where  code  =  0  means  "add  1  to  occurs", 

=  1  means  "subtract  1  from  occurs". 

4  Insert  a  filler  (PIC  X)  in  a  record.  This  mutation  is 

aided  by  the  fact  that  the  parser  inserts  a  dummy  record 
between  each  data  item  in  the  symbol  table;  this  was 
done  so  that  the  references  in  the  code  array  to  the 
SYMBOL  TABLE  will  not  be  affected  by  implementing  this 
mutant . 

<INSERTXS YMBOL  TABLE  locat ionXxXx> 

5  Change  a  filler's  size  by  adding  or  subtracting  1  to  its 

si  ze . 

CCHANGE-FILLERXSYMBOL  TABLE  location><+l  |  -lXx> 

6  Reverse  adjacent  elementary  items  in  a  record.  This  is 

accomplished  by  reversing  the  memory  pointer  contained 
in  the  SYMBOL  TABLE. 

<RE  VERS  EXSYMBOL  TABLE  location> 

<next  elementary  locationXx> 

7  Input/Output  reverses  two  file  reference4s  for  input  files 

or  for  output  files. 

<F  ILEXstatementXx> <new  file-code> 

8  DELETE  mutant  deletes  a  statement  from  the  program  by  mak¬ 

ing  it  a  NO-OP.  This  mutation  checks  for  the  necessity 
of  a  statement. 

<DELETEXstatement>  <x>  <x> 

9  GO-TO  changed  to  a  PERFORM  statement  is  implemented  by 
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changing  the  opcode. 

<GO-PERFORMXstatementXxXx> 

10  PERFORM  changed  to  a  GO  TO. 

<PERFORM-GO  TO> <statement> <x> <x> 

11  THEN-ELSE  clause  reversal  is  implemented  by  negating  the 

condition.  A  special  opcode,  NIFOP,  was  created  for  im¬ 
plementing  this  mutant. 

<THEN-ELSEXstatement>  <x>  <x> 

12  STOP  replacement  mutation  consists  of  changing  a 
statement  to  a  STOP  statement  to  verify  the  necessity  of 
a  statement's  existence. 

<STOPXstatement><xXx> 

13  THRU  clause  adjustment  extends  the  range  of  a  PERFORM 

statement.  <THRUXstatement> <new  parag raph> <x> 

14  TRAP  statement  mutation  consists  of  inserting  a  TRAP 
statement  into  the  program  after  possible  transfer 
points  for  path  analysis. 

<TRAPXsta  tement>  <x>  <x> 

15  ARITHMETIC  OPERATION  SUBSTITUTION  changes  one  arithmetic 
verb  for  another.  For  example,  change  ADD  to  SUBTRACT. 

<ARITHMETIC-lXstatementXnew  ope  ratio  nXx> 

16  COMPUTE  OPERATION  SUBSTITUTION  exchanges  an  operand  in  a 

compute  statement. 

< ARITHMETIC -2 XstatementXf ieldXnew  operation> 
where  'field'  is  the  relative  location  in  the  code 
description  of  the  operator  to  be  changed. 


17  PARAMETER  ALTERATION  is  used  in  COMPUTE  statements  to 
change  the  position  of  a  parenthesis  by  moving  one 
parenthesis  one  place  to  the  left  or  right. 
<PARENXstatementXf  rom-f  ield>  <to-  f  ield> 

where  the  'from-field'  is  the  relative  location  in 
the  code  description  of  the  parenthesis  in  the  COMPUTE 
statement  being  altered  and  the  'to-field'  is  the  loca¬ 
tion  to  which  the  parenthesis  is  to  be  moved. 
j.8  ROUND  mutation  turns  the  'rounded'  condition  on  or  off  in 
an  arithmetic  statement;  ROUNDED  is  changed  to  trunca¬ 
tion  and  vice  versa. 

<ROUNDXstatementXxXx> 

19  MOVE  mutation  reverses  the  direction  of  the  MOVE  opera¬ 

tion  when  only  two  fields  are  used,  if  such  a  reverse 
would  be  a  legal  Cobol  statement.  For  example, 

MOVE  DATA-1  TO  DATA-2 .  changed  to 
MOVE  DATA-2  TO  DATA-1. 

<MOVEXstatementXxXx> 

20  LOGICAL  OPERATOR  REPLACEMENT  is  implemented  by  changing  a 

logical  operator  to  a  different  logical  operator. 
<LOGICXstatementXf ieldXnew  value> 

where  'field'  is  a  relative  location  in  the  code 
description  for  the  logical  operator  being  altered. 

21  SCALAR  for  SCALAR  replacement  changes  the  reference  from 
one  scalar  to  another  scalar  in  a  statement. 

<SCALAR-SCALARXstatementXf  ield> 
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<new  SYMBOL  TABLE  location> 
where  'field'  is  the  relative  location  in  code 
description . 

22  CONSTANT  for  CONSTANT  replacement  replaces  one  reference 
to  a  constant  with  another  constant  reference. 

CCONSTANT-CONSTANTXstatementXf ield>  <new  location> 

23  CONSTANT  for  SCALAR  replacement. 

CCONSTANT-SCALARXstatementXf ieldXnew  location> 

24  SCALAR  for  CONSTANT  replacement. 

<SCALAR-CONSTANTXstatementXf ieldXnew  location> 

25  CHANGE  CONSTANT  mutant  is  used  to  change  a  numeric 

constant  by  +1%,  -1%,  +1,  or  -1  whichever  is  largest. 

To  ease  the  implementation  of  this  mutant,  'mutant' 
values  for  each  numeric  constant  have  been  inserted  in 
the  SYMBOL  TABLE  right  after  the  constant  has  been 
inserted  during  the  parse. 

<CHANGE-NUMERIC-CONSTANTXstatementXf  ield> 

<new  location> 


LOG  FILE 

The  LOG  FILE  is  used  to  contain  important  information 
about  a  CMS.l  session.  This  file  is  a  sequential  file  which 
can  have  some  of  its  contents  determined  by  the  user  (e.g. 
by  issuing  an  OUTPUT  command).  The  CMS.l  system 
automatically  stores  some  information  in  the  LOG  file.  Dur¬ 
ing  the  PRE-RUN  phase  a  copy  of  the  Cobol  source  program  is 
placed  in  the  file.  For  each  test  case,  the  input  file  is 


stored  with  the  result  for  that  test  case;  the  results  are 
TEST  CASE  FAILED,  TEST  CASE  REJECTED,  and  TEST  CASE  #  ENTER 
AND  ACCEPTED.  During  the  MUTATION  phase  a  list  of  the 
mutant  types  that  are  currently  enabled  is  stored  in  the  LOG 
file.  The  POST-RUN  phase  stores  the  status  information  for 
the  pass.  If  the  user  marks  any  mutants  equivalent,  then 
the  number  marked  is  stored  in  the  file.  The  user  may  have 
a  list  of  the  live  mutants  stored  in  the  file  or  a  list  of 
the  test  cases  stored  by  specifying  the  OUTPUT  command.  If 
the  user  aborts  the  run  by  issuing  a  KILL  command,  then  he 
is  asked  to  enter  a  message  explaining  the  reason  for  abort¬ 
ing  the  run.  This  message  is  terminated  by  a  control-C  and 
is  placed  in  the  LOG  file. 
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CHAPTER  III 

EXPERIENCE 

Cobol  Example 

The  following  is  a  script  of  a  CMS.l  run  on  a  program 
originally  from  the  Army  SIDPERS  personnel  system.  The 
program  has  been  modified  somewhat,  mainly  in  the  reduction 
of  the  record  sizes  to  make  a  better  CRT  display.  The 
program  takes  as  input  two  files,  representing  an  old  backup 
tape  and  a  new  one.  The  output  is  a  summary  of  the  changes. 
The  input  files  are  assumed  to  be  sorted  on  a  key  field. 
The  program  has  1195  mutants,  of  which  21  are  easily  seen  to 
be  equivalent  to  the  original  program.  Initially  ten  test 
cases  were  generated  to  eliminate  all  of  the  nonequivalenc. 
mutants.  Subsequently  a  subset  of  five  test  cases  was  found 
to  be  adequate  for  the  task.  The  entire  run  took  about  10 
minutes  of  clock  time,  and  2  minutes  and  13  seconds  of  CPI’ 
time  on  the  PRIME  400. 

The  following  is  an  example  of  the  CMS.l  run.  User  in¬ 
put  has  been  entered  in  lower  case  to  distinguish  it  from 
the  system  instructions  and  prompts.  This  is  the  interac¬ 
tion  at  the  pre  run  phase  where  the  user  has  requested  the 
program  being  tested  be  displayed  at  the  user's  console. 


in  I* iiiMiiHa 
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WELCOME  TO  THE  COBOL  PILOT  MUTATION  SYSTEM 

PLEASE  ENTER  THE  NAME  Of  THE  COBOL  PROGRAM  F ILE :» loO'Changct 
00  YOU  WANT  TO  PURSE  WORKING  TILES  TOR  A  tRESH  RUN  Y>y*t 
PARSING  PROGRAM 

savins  internal  form 

WHAT  percentage  or  the  substitution  mutants  do  you  want  to  createyri 33 
creating  mutant  descriptor  records 

PRE-RUN  PHASE 

DO  YOU  WANT  TO  SUBMIT  A  TEST  CASE  T  RaroBfA* 

PROGRAM  last  compileo  on  t  it  to. 

1  IDENTIFICATION  DIVISION. 

2  PROGRAM-IO.  POOAACA • 

3  AUTHOR.  CPT  R  W  M0REHEAD. 

A  INSTALLATION.  NOS  JSACSC. 

5  DATE-WRITTEN.  OCT  1973. 

6  REMARKS. 

7  this  program  prints  out  a  list  of  changes  in  the  etf. 

B  ALL  ETF  CHANGES  WERE  PROCESSED  PRIOR  TO  THIS  PROGRAM.  THE 

9  OLD  ETF  AND  THE  NEW  ETF  ARE  THE  INPUTS.  BUT  THERE  IS  NO 


10 

further  processing  of  the  etf 

HERE  . 

TN( 

ONLI  OUTPUT  IS 

11 

LISTING  or  THE  ADDS,  CHANGES, 

AND  DELETES.  THIS  PROGRAM 

12 

FOR  HR  USE  ONLY  AND  MAS  NO  APPLICATION  IN  THE  FIELD. 

13 

14 

MODIFIED  FOR  TESTING  UNDER  CPMS  BY 

ALLEN  ACRFE 

15 

JULY,  1979. 

16 

ENVIRONMENT  DIVISION. 

17 

CONFIGURATION  SECTION. 

IS 

SOURCE-COMPUTER.  PRIME. 

19 

OBJECT-COMPUTER.  PRIME. 

23 

INPUT-OUTPUT  SECTION. 

21 

FILE-CONTROL. 

22 

SELECT  OLO-ETF  ASSIGN  1NPUT1. 

23 

SELECT  NFW-ETF  ASSIGN  INPUT2. 

24 

SELECT  PRNTR  ASSIGN  TO  0UT*UT1 

• 

25 

DATA  DIVISION. 

26 

FILE  SECTION. 

27 

FD 

OLO-ETF 

28 

RECORD  CONTAINS  63  CHARACTERS 

29 

LABEL  RECORDS  ARE  STANDARD 

30 

DATA  RECORD  IS  OLD-RIC. 

31 

01 

OLD-REC. 

32 

03  FILLER 

PIC 

K. 

33 

03  OLD-KEY 

PIC 

X(12). 

3A 

03  FILLER 

PIC 

K ( 67) * 

35 

FO 

NEW-ETF 

36 

RECORD  CONTAINS  S3  CHARACTERS 

37 

label  records  are  standard 

3B 

DATA  RECORD  IS  NEW-REC. 

39 

01 

NEW-REC. 

40 

03  FILLER 

PIC 

X. 

41 

03  NEW-KFT 

*IC 

X(T2) . 

42 

03  EILLER 

PIC 

*(67). 

43 

FD 

PRNTR 

44 

RECORD  CONTAINS  A3  CHARACTERS 

45 

LABEL  RECORDS  ARE  OMITTED 

46 

DATA  RECORD  IS  PRMT-LINE. 

47 

01 

PRMT-LIME 

PIC 

*(43) . 

48 

WORKING-STORAGE  SECTION. 

49 

01 

prmT-work-area. 

53 

03  LINE  1 

PIC 

*(50). 

51 

33  LINE2 

PIC 

*(33> . 

52 

33  LINE3 

PIC 

*(23). 

S3 

01 

PRMT-OUT-OLO. 

54 

03  WS-LN-1. 

55 

05  FILLER 

PIC 

*  V4LUE  SPACE. 

56 

05  FILLER 

PIC 

*«**  VALUE  >0 

$7 

05  LN1 

PIC 

*(50). 

SB 

05  FILLER 

PIC 

***  VALUE  SPACES 

59 

03  WS-LM-2. 

63 

05  FILLER 

PIC 

1  VALUE  SPACE. 

61 

05  FILLER 

PIC 

1**1  VALUE  'L 

62 

05  LN? 

PIC 

*(30) . 

63 

OS  FILLER 

PIC 

XV*  VALUE  SPACES 

64 

03  WS-LN-3. 

65 

05  FILLER 

»IC 

1  VALUE  SPACE. 

66 

05  FILLER 

PIC 

IIII  VALUE  '6 

67 

05  LN3 

PIC 

*(20). 

68 

OS  FILLER 

PIC 

IX*  VALUE  SPACE 
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PDNT-NEU-OUT. 


70 

OS 

NEW-LN-1. 

71 

05 

FILLED 

72 

35 

N-LN1 

7S 

05 

FILLER 

7A 

OS 

NEW-LN-2. 

75 

35 

FILLED 

74 

05 

N-LN2 

77 

05 

FILLED 

7S 

OS 

NEW' 

-LN-S. 

79 

05 

FILLED 

S3 

0$ 

N-LN3 

SI 

05 

FILLED 

pic  mu  value  •  n 

vie  X<S3>. 

vie  XXX  value  space. 

VIC  XXXXX  VALUE  •  E 
VIC  XISOJ . 

Vtc  XXX  VALUE  SPACES. 

VIC  XXXXX  VALUE  *  V 
VIC  X<?0>. 

VIC  XXX  VALUE  SPACES. 


PROCEDURE  DIVISION. 

0105-OPENS. 

OPEN  INPUT  OLD-RTF  NEN-ETF. 

OPEN  OUTP’JT  PANTD. 

O113-OLD-REA0. 

READ  OLO-ETF  AT  END  CO  TO  31&0-0L0-C0F . 
0120-NEU-READ. 

READ  NEW-ETF  AT  END  CO  TO  01 TO-NEW-EOf . 
0130-C0HPARES. 

IF  OLO-XET  ■  NEW-XFY 
NEXT  SENTENCE 

ELSE  SO  TO  0U3-CX-ADD-DEL. 

IT  OLO-REC  ■  NEW-REC 

CO  TO  5110-OLD-READ. 

ROVE  OLO-REC  TO  PRNT-WORX-AAEA. 

VERFORN  0210-0LD-VRT  THRU  0210-EXIT. 

ROVE  NEW-REC  TO  PRNT-UORX-AREA. 

VERFORN  3230-NW-WRT  THRU  3203-EXIT. 

GO  TO  OIIO-OID-REAO. 

01L3-CX-A00-DEL. 

IF  OLO-XET  >  NEH-XET 

ROVE  NEW-REC  TO  PRNT-UDRX-AREA 
VERFORR  0200-NU-VRT  THRU  D20D-CXIT 
CO  TO  01 20-NEV-RCAD 
ELSE  SO  TO  31S3-CX-AD0-DEL. 

3153-CX-ADO-DEL. 

Rove  OLO-REC  To  “RNT-W3AX-AAEX. 

PERFORR  0210-0LD-HRT  THRU  0213-EXIT. 

RE  AO  OLO-ETF  AT  END 

HOVE  NEW-REC  TO  PRNT-UORX-AREA 
PERFORR  0203-NW-WRT  Thru  020D-EXIT 
GO  TO  0160-0LD-E0F. 

SO  TO  3150-CONPARES. 

01S3-0L0-E0F. 

READ  NEU-ETF  AT  END  CO  TO  D1S0-E0J. 

ROVE  NEU-REC  TO  PRNT-UORX-AREA. 

PERFORR  0233-NV-VRT  THRU  0233-EXIT. 

SO  TO  31 63-OLO-EOF • 

3120-NEU-E0F. 

ROVE  OLO-REC  TO  VRNT-UORX-ARE A. 

PERFORR  0210-OuD-WAT  THRU  3210-EXIT. 

READ  OLO-ETF  AT  END  CO  TO  3180-E0J. 

SO  TO  0170-NEW-f OF. 

31S0-E0J • 

CLOSE  OLO-ETf  NEW-ETF  PRNTR. 

STOP  RUN. 

3203-NU-URT. 

ROVE  LINE1  TO  N-LNT . 

ROVE  LIRE2  TO  N-LN2. 

ROVE  LINES  TO  R-LN3. 

WRITE  PRNT-LINE  f»OR  NEU-LN-1  atter  AOVARCINC  2. 
WRITE  PRNT-LINE  FRON  NIW-LN-2  AFTER  AOVANCINC  1. 
WRITE  PRNT-LINE  FROR  NEW-LN-3  ArTER  AOVANCINC  t. 
3233-EXIT. 

EXIT. 

0210-OLD-VRT. 

HOVE  L1HE1  TO  INI. 

HOVE  LINE2  TO  CN2. 

HOVE  LINES  TO  LNS. 

WRITE  PRNT-LINE  FROR  WS-LR-1  AFTER  ADVARCIRS  2. 
WRITE  PANT-LIRE  FROR  WS-lN-2  AFTER  ADVANCING  T. 
WRITE  VANT-l I  NT  FROR  WS-LN-5  AFTER  ADVANCING  1. 
0210-E1IT. 

EXIT. 
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Now,  the 
asks  for  each 
the  results 
test  case  for 
CNS.1  these  a 
by  file  name, 
sion. 


user  is  asked  to  enter  a  test  case.  CIS.I 
Cobol  inout  file  by  naae.  The  input  files  and 
are  disalayed  for  the  user  at  his  console,  k 
this  program  is  a  pair  of  input  files.  In 
ay  be  created  outside  the  system  and  referenced 
or  may  be  entered  "on  the  fly"  during  the  ses- 


WHERE  1$  OLD-ETf? 

>U9 

WHERE  IS  VEW-ETFT 

>1(5 

OLD-ETf  PROVIDED  TO  THE  PROSRAH 

I123*5678901221IIIllllI0JJJJJJJJJXXXEXXKXXKLLLLLLLLLLNNVNWVNNNWPPB3339335SGGaS 
J23*567893173YYYYYYYYYYGSSSSGSCG«FFFFfFFf  rFDDDDDDDDDDSSSSSSSSSSXXXXIIHXXEEEEE 

HEW-ETF  PROVIDED  TO  THE  PROGRAH 

I 133* 5678901 200000300003003300003000300000000000D00000000000030000 30 3330003330 
J23* 5678931 73YYYYYYTYYYGCSGGCGC«GFFFf FFFf FF DDDDDDDDDDSSSSSSSSSSIXXXX XIXXIEEE EE 
3*5678931 2  3*UUUUUUUUUOH<4HHHHHHH93S6tG3tGG6DD3DDDDDDDSSSSSSSSSSE  EE  EEEEiEEAA*** 

prhtr  as  .fritter  by  The  prograh 

0  1123*567890121  1 1 1 1 1  X  II I OJ  J  J  J  J  J 
L  JJJKKKXKKXXKKLLLLLLLLLLVHNNVVN 
D  N9N9333933BS3GSGGGG3 

V  1133*5678901200000030000000000 
E  000030000000000000000300300000 
W  00003000000030000000 

0  J 23*5678901 23YYYYYYYYYY5S663CG 
L  GGGFFFFFFf FFf ODDDDDDDDDSS SSSS S 
0  SSSXIXXXXXXXXEEEEEEE 

H  J234567990123VYYYYYYTTYSSSSCSG 
E  GSSFFFFFFFF FFDDDDDBDDDDSSSSSSS 
*  SSSXIXXXXXXXXEEEEEEE 

•I  3*5678901 234UUUUUUUUUUHHHHHHH 
E  HHHGSSGGSGSSSDDODDDOOODSSSSSSS 
4  S8SEEEEEEEEEE******* 

THE  PROSRAR  TOOK  8*  STEPS 
IS  THIS  TEST  CASE  ACCEPTABLE  T  >y»* 

•0  YOU  WAIT  TO  SUBHIT  A  TEST  CASE  T  »no 


*; 


» 


U3 


The  following  is  the  interaction  necessary  during  the 


mutation  phase, 
programs  are  to 


The  user  must 
be  executed. 


indicate 


which 


mutant 


type 


MUTATION  PHASE 

MHAT  NEW  MUTANT  TYPES  ARE  TD  IE  CONSIDERED  T  PloUct 

ehtee  the  numbers  or  the  mutant  types  you  want  to  turn  on  at  this  tine. 


4 

5 

6 

7 

8 

10 

11 

12 

IS 

14 

19 

20 
21 
22 
23 
23 


••••  INSERT  TILLER  TYPE  »«•• 

TILLER  SHE  ALTERATION  TYPE  »••• 

....  ELEMENTARY  ITEM  REVFRSAL  TYPE 
»»••  TILE  REFERENCE  ALTERATION  TYPE  »».« 
....  STATEMENT  OELETION  TY»E  »»»• 

....  PERFORM  --)  so  TO  TYPE  .... 

....  THEN  -  ELSE  REVERSAL  TYPE 

....  STOP  STATEMENT  SUBSTITUTION  TYPE 

....  THRU  CLAUSE  EXTENSION  TYPE  *»•• 

....  TRAP  STATEMENT  REPLACEMENT  TY»E  ...» 
....  HOVE  REVERSAL  type  .... 

....  logical  operator  replacement  type  «... 

»•»»  SCALAR  TOR  SCALAR  REPLACEMENT  .... 

....  CONSTANT  TOR  CONSTANT  REPLACEMENT  ...» 
....  CONSTANT  TOR  SCALAR  REPLACEMENT  .... 
....  CONSTANT  ADJUSTMENT  .... 


TYPES  7  >4  to  14  stop 


The  oost  run  phase  displays  the  mutant  status  as  a 


result  of  the  test  cases  currently  defined.  The  jser  is 


given  the  opportunity  to  see  the  live  mutants  and  the 
equivalent  mutants  during  this  phase  and  must  indicate  i+ 
the  session  is  to  be  continued  or  not.  For  this  example, 
the  user  specified  the  ’loop'  option  so  that  the  C^S  session 
will  continue. 


-  TESTC.SE  1  - 

250 

2S4  CONSIDERED 


mutant 

TY»E 

STATUS 

TOTAL 

LIVE 

INSERT 

41 

7 

T1LLSI 

38 

14 

ITEMRV 

21 

0 

TILES 

5 

1 

DELETE 

54 

13 

PER  SO 

7 

2 

IF  REV 

3 

1 

STOP 

53 

10 

THRU 

8 

2 

TRAP 

54 

13 

224  KILLED  SO  REMAIN 


»CT  E3UIV 

82.93  0 

63.16  3 

100.00  3 

B3.00  3 

75.93  0 

71.43  3 

66.67  3 

81.13  3 

75.00  3 

SI. 48  3 


TOTALS 

284  63  78.87  0 

00  YOU  WANT  TO  SEE  TNI  LIVE  MUTANTS?>no 
00  YOU  WANT  TO  SEE  THE  EOUI VALENT  MUTANTS?>no 
WOULD  YOU  LIKE  TO  SEE  THE  TEST  CASE S1>oo 
LOOP  OR  HALT  T  >1000 
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The  user  has  indicated  that  the  session  is  to  continue. 

PRE-RUN  PHASE 

DO  VOU  WANT  TO  SUDN1T  A  TEST  CASE  ?  >y»» 

where  is  olo-ettt 

>lcis 

WHERE  IS  WEWETET 
>1*5 

OLD-ETf  PROVIDED  TO  THE  PROSRAH 

000000000001 21 I I II1IIIIJJ JJJJJJJJKKKKKKrrKKLLLLLLLLLLNNNNNNNNNNBBBB339BS9GGGGG 
I123456709012I1IIIIII II J J JJ J  J J J J JKKKKKKKKKKLLLLLLLLLLHNNNHNNNNNBBBBSBBIDBGSGGG 
A234567S90123YYYYYYYYYYSSSSSS6SS6FFFFFFFFFFDDDDDDDDDDSSSSSSSSSSXXXXIIXXIIEEEiE 

HEW-ETF  PROVIDED  TO  THE  PROSRAH 

1 12 34 S670901 211 1  III I III J JJI2 JJ J J JKKKKKCKKKKLLLLLLLLLLNHNNNNNNNNB6B3D9B39BSGG5S 
J234567890123YVYYVYYYYY6SS6GGS6SSFFFFFFFFFFDDDDDDDBDDSSSSSSSSSSXXXKXXXKXXEEEIE 

PRHTR  AS  WR1TTEH  BT  THE  PROSRAH 

0  000030000001211III1IIIIJJJJJJJ 

l  JJJKCKKKKCKKKLLLLLLLLLLHNNNYNN 
D  HNNB9B8B9S9B9GG66GG3 

The  prograh  took  **  steps 
IS  this  test  case  ACCEPTABLE  t  >ye* 

DO  TOU  WANT  TO  SURHIT  A  TEST  CASE  T  >yt* 

WHERE  IS  OLD-ETF? 

>t*14 

WHERE  IS  HEW-ETF? 

>1*5 

OLD-ETF  PROVIDED  TO  THE  PROGRAH 

II 234567090121 II 1 II III 1KJ JJJJ JJJJKKKKKKKKKKLLLLLLLLLLNNNNNNNNNNBBB93399B96SGSS 
J234567B90123yyVYYVYYVVSSG6ESSESSFFFFFFFFFFDDDDDDDBDDSSSSSSSSSSXXXXXikxxxEEEEE 

HEW-ETF  PROVIOED  TO  THE  PROSRAH 

1123456759012111 1 1 1 1 1 1 X J J J J J  J J J J JKKKXKKKKKKLLLLLLLLLLNWNNWNNNNW5BB3333333SGGGS 
J 2345670901 23YY Y YY YYYYYGGGSSGGGGGFFFFFFFFFFDDDDDDDDDDSSSSSSSSSSXXXXXX I IX XEEE EE 

PRHTR  AS  WRITTEN  OY  THE  PROSRAH 

0  I123456709D12I11IIII1IIKJJJJJJ 
L  jjjkkkkkkkkkkllllllllllnhnnnnn 
D  HNNBB938BBBBBGGGGGGG 

N  1 1 2345670901 21 1 1 II II IIIJJJJJJJ 
E  JJJKKKKKKKKKKLLLLLLLLLLNHNNNNN 
W  NNN8090B000B0C6GGGGG 

THE  PROSRAH  TOOK  40  STEPS 
IS  THIS  TEST  CASE  ACCEPTABLE  ?  >y»» 

00  YOU  WANT  TO  SUOHIT  A  TEST  CASE  T  >yt« 

WHERE  IS  OLD-ETF? 

>1*11 

WHERE  IS  HEW-ETF? 

>1*1 

OLD-ETF  PROVIDED  TO  THE  PROSRAH 
00000000000000000000000000000000000000000000 
HEW-ETF  PROVIOED  TO  THE  PROSRAH 

1 12345670901 2111 II  III  I I J J J JJ J J JJ JKKKKKKKKKKLLLLLLILLLNNNNNNNNNNBBBB9999B9ES6C6 
J234S67090123YYTYYYYTYYS6SESSSES6FFFFFFFFFFDDDDDDDDDDSSSSSSSSSSXXXIXXXXXXEEEEE 
345670901 234UUUUUUUUUUHNHHHHHHHNCSSESSCSSSDDDDDDDDDDS$SSSSS$$SEEEEEEEEEE AAAAA 

PRHTR  AS  WRITTEH  BY  THE  PROSRAH 

0  000000000000000000000000000000 

L  00000000000000 

B 

H  1 12345670901 71 1 IISIIIllUWJWJJJ 

E  JJJKKKKKKKKKKLLLLLLLLLLNHNNNNN 
W  HHH0B003B00BBSSSSGSG 
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N  j234557B90123yyyyyyyyyycs6GG5G 
E  GGGFF F F FT F F FFDBDDDDDDDOSSSSSSS 
y  sssmmi»i(EC(Eii 

N  3455789312 34 UUUUUUUUUUHHMHHHM 
E  HHHGGGGoGGGGGDDDDDDDDBDSSSSSSS 
W  SSSEEEEEEEEEE4444444 

THE  PROGRAM  TOOK  64  steps 

is  this  test  case  acceptable  ?  >y«i 

00  TOU  HAST  TO  SUBHIT  A  TEST  CASE  ?  >yt* 

where  is  olo-etf? 

>le1 

where  is  MEW-ETF* 

>lc11 

OLO-ETF  PROVIDED  TO  THE  PROGRAM 

I123456789D12I1IIIIIIIIJ.IJJJJJJJJKKKKKKKKKKLLLLLLLLLLNNNNNNNNNNS9B3333BB3GCGGG 
J 2345678901 23YYVYYYYYYVS3CSSSG665FFFFFFFFFFDDDDDDDDDDSSSSSSSSSSXXX XX FX XXX EEC  EE 
345678901 234UUUUUUUUUUMHHHHHMHMH6GGSGGGSC6DDDD0DDDDDSSSSSSSSSSFEEEEEEEEE4AA44 

hew-etf  provideo  to  the  »rog»am 

03300030030000000033000330030000330030000000 

PRHTR  AS  WRITTEN  BY  THE  PROGRAM 

H  OOOOOOOODOOOOOOOOOOOOOOOOOOOOO 

E  00003000000003 

w 

0  I1234567B9012III11I1I1IJJJJJJJ 
L  JJJKKKKKKKKKKLLLLLLL LLLNNNNNNN 
D  NNH9BBB9BSB8BGG6GSGG 

0  J  2345678901 23v  YYYYY Y YYVGGGCGCG 
L  GGGFFFFFFFFFFDDDDDDBDDDSSSSSSS 
0  SSSXXXXXKXXXXEEEEEEE 

0  345678901234UUUUU0UUUUHHHHHHM 
L  HHHGGSCGCGGGCBBBBBOBBBBSSSSSSS 
D  SSSEEEEEEEEEEAAAAAA* 


THE  PROGRAM  TOOK  64  STE“S 
IS  THIS  TEST  CASE  ACCEPTABLE  T  >y*i 
03  TOU  WANT  TO  SUBMIT  A  TEST  CASE  T  >no 
NUTATION  PHASE 

WHAT  NEW  MUTANT  TYPES  ARE  TO  BE  CONSIOEREB  7 

--T  TESTCASE  1  - 

250 

533 

750 

814  CONSIDERED  640  KILLED 

---  TESTCASE  2 

234  COHSIDERCO  87  CKtEB 

-  TESTCASE  3  - 

152  CONSIDERED  1  KILLED 

-  TESTCASE  4  - 

151  CONSIDERED  61  KILLED 

— -  TESTCASE  5  - 

90  CONSIDERED  69  KILLED 


61  KILLED 
69  KILLED 


MUTANT 

STATUS 

TYPE 

TOTAL 

LIVE 

PCT  1 

INSERT 

41 

3 

92.63 

FILLS! 

38 

12 

68 .42 

ITENRV 

21 

0 

103.00 

FILES 

5 

3 

103.00 

DELETE 

54 

1 

98.15 

PER  GO 

7 

0 

103.00 

IF  REV 

3 

3 

103.00 

STOP 

S3 

3 

133.03 

thru 

8 

3 

103.00 

TRAP 

54 

3 

103.00 

N3VE  R 

13 

3 

103.03 

LOGIC 

15 

1 

93.33 

SU9SFS 

704 

4 

99.43 

SUBCFC 

12 

3 

100.00 

SU9CFS 

38 

3 

190.03 

C  ROW 

12 

3 

100.03 

0 

0 

3 

3 

0 

0 

0 

0 

0 

0 

3 

0 

0 

0 

0 

0 


>•11 

174  REMAIN 
152  REMAIN 
151  REMAIN 
90  remain 

21  REMAIN 


TOTALS 


1098 


21  98.09 


0 


t 
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00  YOU  WONT  TO  SEE  THE  U  YE  RUTANTS?>yn 
THE  LIVE  NUYaNTS 

FOR  EACH  NUTART  :  HIT  RETURN  TO  CONTINUE.  TYPE  ‘STOP*  To  STOP. 
TYPE  *  EQU1V 1  TO  JUOSE  THE  NUTART  EQUIVALENT. 

•  ••«  INSEtT  FILLER  TYPE  *»*» 

there  are  s  mutants  of  this  ty»e  left. 

00  YOU  WANT  TO  SEE  THEMY»y»» 

A  FILLER  OF  LENSTH  ONE  HAS  SEEN  INSERTED  AFTER 

the  item  vhich  starts  on  line  52 
ITS  LEVEL  MUNIER  IS  ) 


A  FILLER  Of  LENSTH  ONE  NAS  SEEN  INSERTED  AFTER 
THE  ITER  WHICH  STARTS  ON  LINE  SS 
ITS  LEVEL  NURRER  IS  S 


A  FILLER  OF  LENSTH  ONE  HAS  SEEN  INSERTED  AFTER 
THE  ITER  WHICH  STARTS  ON  LINE  60 
ITS  LEVEL  NURRER  IS  S 


> 


•••»  filler  she  alteration  type 


THERE  ARE 

12 

MUTANTS  OF 

This  type 

LEFT. 

DO  YOU  WANT 

TO 

SEF 

THER?»y»* 

THE 

FILLER 

ON 

LINE 

$8 

HAS  HAD 

ITS 

SIZE 

DECREMENTED 

IT 

ORE 

> 

TMf 

FILLER 

ON 

LINE 

SS 

NAS  HAO 

ITS 

she 

INCREMENTED 

■  Y 

ORE 

> 

TMf 

FILLER 

ON 

LINE 

63 

HAS  HAD 

ITS 

she 

decremented 

NY 

ORE 

> 

the 

FILLER 

ON 

LINE 

63 

NAS  HAD 

ITS 

SHE 

INCREMENTED 

RY 

ORE 

> 

the 

FILLER 

OH 

LINE 

68 

HAS  HAD 

ITS 

SHE 

DECREMENTED 

DY 

ORE 

> 

TH€ 

FILLER 

ON 

LINE 

66 

HAS  HAD 

ITS 

SHE 

INCREMENTED 

OY 

ORE 

> 

THE 

FILLER 

OH 

LINE 

73 

HAS  HAD 

ITS 

SHE 

DECREMENTED 

BY 

ORE 

> 

the 

FILLER 

ON 

LINE 

73 

HAS  HAD 

ITS 

SHE 

incremented 

BY 

ORE 

k 

> 

THE 

FILLER 

ON 

LINE 

77 

MAS  RAD 

ITS 

SHE 

decremented 

DY 

ORE 

f 

f. 

> 

the 

FILLER 

ON 

LINE 

77 

HAS  HAD 

ITS 

SHE 

INCREMENTED 

DY 

ONE 

> 

the 

FILLER 

ON 

LINE 

81 

HAS  HAO 

ITS 

SHE 

DECREMENTED 

DY 

ONE 

i 

> 

the 

FILLER 

ON 

LINE 

81 

MAS  HAD 

ITS 

SHE 

INCREMENTED 

DY 

ONE 

f  i 


«•••  statement  deletion  type  •  ••• 


THERE  are  1  MUTANTS  OF  THIS  TYPE  LEFT. 

00  YOU  WANT  TO  SEE  THEMTPRRi 
ON  LINE  106  THE  STATERENT: 

SO  TO  OISO-CC'AOO'DEL 
NAS  NEEN  DELETED. 


••••  LDSICAL  OPERATOR  REPLACEMENT  TYPE  •••• 


i 


there  are  i  mutants  of  this  ty®e  left 

DO  YOU  WANT  TO  SEE  TNEN?>y«s 
ON  LINE  132  THE  STATEMENT: 

If  olo-cet  >  new-ret 

HAS  SEEN  CHANGED  TO: 

If  OLO-EEY  NOT  <  NFW-EEY 


••••  scalar  for  scalar  replacement 
there  are  a  mutants  of  this  type  left 

00  TOU  WANT  To  SEE  THEMTPytt 
ON  LINE  129  THE  STATEMENT: 

NONE  LI  NET  TO  N-LNT 
HAS  SEEN  CHANGED  TO: 

MOVE  NEW-REC  TO  N-LN1 


ON  LINE  129  -THE  STATEMENT: 

MOVE  LINE1  TO  N-LN1 
NAS  SEEN  CHANGED  TO: 

MOVE  prnt-worr-arfa  to  n-lni 


ON  LINE  1S8  THE  STATEMENT: 

MOVE  LINE1  TO  LN1 
MAS  SEEN  CHANGED  TO: 

MOVE  OLO-REC  TO  LN1 


ON  LINE  15S  THE  STATEMENT: 

MOVE  LINE!  10  LN1 
HAS  BEEN  CMANGEO  TO: 

MOVE  »RNT-W3RE*AREA  TO  LN1 


DO  TOU  WANT  TO  SEE  THE  EQUIVALENT  MUTANTSTPno 
WOULD  TOU  LIRE  TO  SEE  THE  TEST  CASES?>no 
LOOP  OR  HALT  ?  >hslt 


STOP 


< 


45 


Testing  CMS . 1 

Several  routines  from  the  CMS.l  system  have  been  tested 
on  the  Fortran  Mutation  System  (FMS.2).  The  subroutines 
which  were  chosen  comply  very  closely  to  ANSI  Standard 
Fortran . 

FMS.2  will  accept  any  ANSI  Fortran  program  which  does 
not  use  complex  arithmetic  or  input/output  statements 
[ ABDLS ] .  FMS.2  will  accept  several  subroutines  for  a  test¬ 
ing  run  and  will  also  accept  character  data  as  input  which 
makes  it  possible  to  test  CMS.l  routines  which  store  the 
Cobol  program  and  data  in  character  format. 

Some  of  the  machine  dependent  features  that  had  to  be 
rewritten  were  the  PRIME  Fortran  functions  'AND',  '  INTL ' 
(interger  long),  'OR',  and  'RS'  (right  shift).  The  'RS' 
function  can  be  implemented  by  simple  division;  to  shift 
right  n  bits  divide  by  2  to  the  nth  power.  The  PRIME  func¬ 
tion  INTL,  which  converts  a  16-bit  integer  into  a  'long'  32- 
bit  integer,  can  be  deleted  because  the  FMS.2  test  was  con¬ 
ducted  on  a  36-bit  machine.  The  Fortran  'AND'  function  can 
be  implemented  by  subtraction  and  the  'OR'  function  is  im¬ 
plemented  by  addition,  in  the  context  in  which  they  are  used 
in  the  tested  routines. 

In  CMS.l  a  negative  number  is  coded  with  a  negative 
sign  placed  in  the  low  order  byte  of  the  word  containing  the 
last  character  of  the  least  significant  digit,  all  the  low 
order  bytes  of  the  words  for  the  other  digits  contain  a 
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blank.  Improvising  for  the  negative  sign  on  the  FMS.2 
system  is  accomplished  by  setting  a  bit  in  the  second  byte 
of  the  last  word  of  a  number.  In  FMS.2  a  character  is 
stored  in  the  most  significant  byte  with  the  remaining  4 
bytes  containing  a  blank.  FMS.2  has  an  UNPACK  and  PACK 
routine  that  may  be  used  by  the  user.  The  UNPACK  routine 
takes  an  A5  word  format  and  repacks  it  into  a  five  word  A1 
format.  The  PACK  routine  reformats  5  words  in  A1  formats  to 
a  single  word  with  an  A5  format.  The  UNPACK  and  PACK 
routines  were  used  in  rewritting  two  of  the  routines  that 
use  the  'negative*  sign.  Some  of  the  routines  tested  on 
FMS.2  use  the  subroutines  MAKNEG,  which  turns  the  negative 
sign  mask  on;  MAKPOS,  which  turns  the  negative  sign  mask 
off;  or  the  logical  function  ISNEG  which  determines  if  the 
negative  sign  mask  is  on.  These  three  routines  have  been 
expanded  in-line  to  facilitate  implementation  on  FMS.2.  To 
code  the  MAKPOS  subroutine  it  is  necessary  to  turn  the 
'negative'  bit  off,  this  is  accomplished  by  storing  a  blank 
in  the  second  byte  of  the  word  containing  the  negative  sign 
(call  PACK  with  a  blank  in  the  second  word  which  gets  placed 
in  the  second  byte  of  the  word) .  MAKNEG  is  expanded  in-line 
by  calling  PACK  with  the  low  order  bit  of  the  second  word 
turned  on;  this  word  gets  packed  into  the  second  byte.  When 
MAKNEG  is  invoked,  the  negative  sign  mask  is  off.  ISNEG  is 
expanded  by  calling  UNPACK  and  checking  to  see  if  the  second 
word  is  blank,  not  negative,  or  non-blank,  negative. 
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Another  dependent  feature,  the  $INSERT  command,  has 
been  changed  in  all  the  routines  to  contain  COMMON 
statements  where  needed  or  to  insert  constants  where 
parameters  were  used. 

The  MOVENM  and  MOVENW  routines  are  believed  to  be 
correct  and  the  testing  was  done  to  increase  confidence  in 
the  program's  correctness.  The  two  programs  are  shown  in 
Figure  3.  Mutation  analysis  on  each  subroutine  indicates 
that  no  errors  exist  and  that  the  two  subroutines  are 
correct.  A  listing  of  each  subroutine  with  its  equivalent 
mutants  and  the  MUTANT  STATE  information  is  given  in  Figure 
4.  It  can  be  seen  that  most  of  the  equivalent  mutants  a  e 
the  absolute  value  or  the  never  been  zero  mutant  of  a 
variable;  these  variables  are  always  positive  and  never  zero 
because  they  are  referring  to  the  memory  location  and  length 
for  either  the  sending  field  or  destination  field  in  the 
Cobol  MOVE  statement  and  this  cannot  be  negative  or  zero. 
One  important  note  to  be  made  concerns  the  statement: 

IF  (K  .EQ.  '#')  I ER=4 

This  conditional  checks  for  undefined  data.  If  the  data  is 
undefined,  the  data  is  moved  entirely  to  the  receiving  field 
before  the  interpreter  is  halted  and  an  error  returned  to 
the  calling  subroutine.  The  conditional  statement: 


IF 

(IER  .NE. 

0) 

GO 

TO 

9999  as 

in  MOVENW 

IF 

(IER  .NE. 

0) 

GO 

TO 

50  as  in 

MOVENM 

is  located  after  the  Fortran  DO  loop  that  moves  the  data;  if 
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this  statement  were  moved  inside  the  DO  loop,  then  the  error 
could  cause  the  error  return  before  all  the  data  is  moved. 
After  further  consideration,  it  was  decided  that  evaluating 
the  error  condition  on  every  iteration  is  larger  than  moving 
the  remaining  data  to  the  receiving  field.  It  should  be 
noted  that  moving  the  undefined  data  to  the  receiving  field 
has  no  effect  because  interpretation  of  the  program  is  hal¬ 
ted  . 

The  MOVEED,  numeric  edited  move,  subroutine  was  submit¬ 
ted  for  mutation  analysis  because  it  has  not  been  fully 
tested  by  conventional  means.  The  program  as  modified  for 
FMS.2  is  in  Figure  5. 

The  data  for  this  subroutine  consists  of  the  following 

input  and  input/output  data. 

INPUT  DATA 

SOURCE  -  INTEGER  data  that  contains  the  starting  location 
in  memory  for  the  sending  field. 

SLEN  -  INTEGER  data  that  specifies  the  length  of  the  item 
in  m emo r y . 

SDEC  -  INTEGER  specifing  the  number  of  digits  in  the  frac¬ 
tion  part  of  a  number. 

DEST  -  INTEGER  data  that  contains  the  starting  location  in 
memory  for  the  receiving  field. 

DLEN  -  INTEGER  data  that  specifies  the  length  of  the 
receiving  data  item  in  memory. 

PLEN  -  INTEGER  that  specifies  the  length  of  the  PICTURE 
specification. 

PDIG  -  INTEGER  that  gives  the  number  of  digits  in  the  PIC¬ 
TURE  description. 

PDEC  -  INTEGER  specifying  the  number  of  digits  in  the 
fraction  part  of  the  PICTURE. 


LISTING  TNf  PROERP"  U*'1T  “•('VENN  “ 

SU9R0UTI  *F  vrWFVWfSSURCE  ,SLF  V,DEST,ntF 

INTEGER  *LF*,  ',  SU3?,  SJ’I,  L30P-I],  I.  INI,  I  ;  R 

IVTCSFR  ST*U3,1D),  CODE<33),  $7*144(1.:, 9) 

CN4R  »f«p4l<425> 

rmsis  mN,  oest,  slev,  source 


IV  =  UT  OJT’JT  l£R,  REPORT 
I V°UT  DLEN,  OEST,  SLEV.  SCURCF 

NLCV  «  DLEv  1 

If<SLE>.  ,LT.  VLEV)  »LFV  •  SLEV  2 

L33»NI  *  (DEST  ♦  VIE*)  -  1 

SU»2  «  SOURCE  -  1 

DO  2D  SU*1*0EST,  lOCHl 

SU32  *  SU9?  ♦  1 

r  «  v£«svr«su32> 

IF(K  .ES.  ■«•)  IF*  *  4  7  1 

20  *e*0*Y<SUV1>  *  r  11 

11(1(1  .*£.  3)  6010  9999  1?  13 

I F  ( DIE  V  .LF.  ntV)  SOTO  9999  14  IS 

I  «  LDO’Hl  ♦  1  IS 

LOOPNI  *  (DESt  4  DLIV)  -  1  17 

00  30  $UR1*l,  LODPHI  14 

JD  PE N3RT (SU91 )  *  •  1  17 

9799  CONTINUE  ?j 

RfTURV  21 

EVO 


LISTINS  TNC  PRDGR4N  UNIT  "VOVfVV 

SUBROUTINE  N0VfNN(S0URC£.5LfN.S0FC,DEST,0LFN,DDE:, !!►*£) 
LOGICAL  NECSO 

INTEGER  «  (5)  ,  PTVEGD.  •TVESS.  t.  SUB2,  SU91,  LDO»Hl,  l»VD 
INTEGER  LEVS,  I,  I H I ,  ODEC»T,  SDECPT,  If*.  STvr{3,13) 
INTEGER  COOEC33),  STNT*3<10,0) 

CH»9  VE VC9T (425) 

INTEGER  Tt®PE,  DOEC,  DLEV,  DEST,  SOEC,  SLEV,  SOU»tE 

input  output  ter,  pe*ort 

IV°UT  TfPPF,  ODE t ,  OLEV,  BEST,  SOEC,  SLEV,  S0J9CE 


FTVESS  •  (SOUPCE  ♦  SLEV)  -  1  23 

PTVECS  •  (DEST  ♦  DLCV)  -  1  24 

C*LL  UV»*CC(PE*0»r(PTVESS),*,5>  7S 

VESVO  •  X(2)  .£9,  *-<  26 

X(2>  •  •  •  27 

IMNESVO)  C»LL  P»CX(X,Pf VORTCPTNfSS>,$)  2*  29 

LEVS  •  SLEV  -  SOEC  *0 

LEVO  «  OLEV  -  DOEC  31 

SOEC®f  •  SOUPCE  ♦  LENS  32 

OOFCPT  «  DEST  ♦  LEVD  33 

SUB1  »  ODEC’T  -  1  1* 

I E (SOEC  .ca.  0  .OR.  DOEC  .£*.  0>  SOTO  22  3S  36 

INI  »  (SOEC  ♦  SOECPT)  -  1  37 

I F ( ODE C  .LF.  SOEC)  INI  •  (DDF C  ♦  SPfCPT)  -  T  3«  39 

00  20  SUB2»S0ECP1,  INI  4? 

SUB  1  •  SU»1  *1  41 

t  •  VEV0PT<SJ«2)  42 

IF (C  .E3.  •«•)  IE*  >4  43  44 

20  «EV0*Y(SUB1>  •  *  45 

I E  ( l  f  R  .Vf.  0)  *010  50  46  47 

22  IF  CODEC  .LF.  SDEC)  SOTO  33  43  49 

I  •  5U91  ♦  1  53 

INI  «  (DEST  ♦  OLEN)  -  1  51 

00  2$  SUB1*I ,  INI  52 

25  NE«0*T(SUB1)  ■  *3<  53 

SO  LOOPNI  «  LEVO  54 

lEUENS  .LE.  LIND)  LOOPNI  •  LEVS  55  56 

SUB1  •  OOECPT  59 

SU32  •  SOEC»T  5S 

I M LEND  .E3.  0)  SOTO  50  59  63 

I E< LEVS  ,EB.  0)  SOTO  41  61  <2 

00  40  I«1,  LOOPNI  65 

SJ31  •  SUIT  >1  64 

SUS2  ■  SUN 2  -  1  65 

K  •  NE«0»T«SUS2)  66 

IE(X  ,E7.  •*»>  If»  «  4  62  60 

<3  Nf»0*Y(SUS1)  ■  «  69 

I*  (HR  .ME.  3)  SOTO  5C  23  91 

(E (LE VO  .LE.  LENS)  SOTO  SO  92  93 

41  INI  •  SUP1  -  1  94 

00  43  I pOE ST,  INI  95 

45  PEVORT (I )  «  »0'  76 

SO  XC2)  •  97 

lE(NESVO)  C6LL  PRCE (X,NER0*7(PTVESS),5)  79  79 

IK. NOT.  (VESVO  .4VD,  T»PP|  .E».  2)1  OETUON  S3  IT 

C4LL  UNP*CR(NfV0*1(*TMS0>#*,)>  82 

1(2)  •  PS 

C6LL  •*CR(»,"M0RT(PTVES0>,3)  8* 

of  turn  85 

ENO 


Figure  3  MOVENW  and  MOVENM  Original  Program  Listings 


CR>  >4  •>  v/s  Vp« 
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tiSTisr.  the  uk i t  *p©venu  "  nith  s»eciticb  isjiv  «jt«vts 

SJBROJTINT  N0NIN.F(S3U«CE,StlN,tCST,r>LCN) 

INTESER  NLEN,  (,  SJ32.  SU31.  LOOPHI,  I,  IM1,  It* 

1  NT  F  GE  p  STM  (3,13),  CODE  CSC)  #  SYNTi3(10,9> 

CHtR  "ENO »r(4?5) 

INTE6ER  OLEN,  BEST,  SLEN,  SOURCE 
IN'UT  OUTPJT  1ER,  Pf HO®  T 
IN»UT  PLEN,  OFST,  SLEf  ,  SOURCE 

PLEN  *  DLEN  1 


t  7551 

PLEN  •  IBS  DL  EH 

17571 

PUN  •  {PUSH  OLEN 

IFTSLE*.  .LT.  PLEN)  NLEN  •  SLEN 

? 

J 

1(31 

IF  (  S  L  E  S'  .IT.  OLEN)  *LF  N  •  SLEN 

i«:» 

IF<—  SLEN  .LT.  NLEN)  NLEN  •  SLEN 

14371 

IFESLEK  .LT.  ♦♦  NLE*)  NLEN  *  SEEN 

17271 

IF  (SLEN  .Lf.  **LEN>  NLEN  ■  SLEN 

175*1 

1  f  ( OS  SLEN  .LT.  NLEN)  NLEN  «  SLEN 

17631 

IFIIPUSH  SLEN  .LT.  NLEN)  NLEN  «  SLEN 

§7614 

IF  (SLEN  .LT.  OS  NLEN)  NLEN  •  SLEN 

17431 

IF (SLEW  .LT.  2*USH  *LFN>  NLEN  •  SLEN 

176(1 

IF (SLEN  .LT.  NLEN)  NLEN  «  IBS  SLEN 

17641 

1F(SLEN  .LT.  NLEN)  NLEN  ■  I»JSH  SLEN 

LOOPHI  «  (OFST  ♦  NLEN)  -  1 

4 

1767$ 

LOOPHI  *  (IBS  BEST  ♦  NLEN)  -  1 

17651 

LIHOmI  >  (?PUSH  OFST  ♦  NLEN)  -  1 

17731 

LOOPHI  •  (BEST  »  IBS  »LEN)  -  1 

17771 

LOOPHI  «  (BEST  ♦  2PJSP  NLEN)  -  1 

17731 

L00°HI  «  IBS  (BEST  ♦  PLEN)  -  1 

177S1 

L  00°HI  *  2pUSh  (BEST  ♦  NLEN)  -  1 

17761 

L003hj  •  IBS  ((BEST  •  NLEN)  -  1) 

177m 

L  93  ®HI  «  2pUSH  ((BEST  ♦  NLEN)  -  T) 

SJN7  •  SOU® CE  -  1 

3 

17791 

SJB7  •  (PS  SOURCE  -  1 

$7»11 

S‘JB?  *  2PIISH  SOURCE  -  1 

17*71 

SJ32  *  (PS  (SOURCE  -  1) 

176(1 

SUB2  «  2 PUSH  (SOURCE  -  1) 

80  70  SUP1*0EST,  100»HI 

6 

17E31 

00  20  SUMMSS  BEST,  LOO*Hl 

17871 

03  20  SUB1*2*USN  BEST,  U93PHI 

17SN1 

BC  20  SUM  *0E  ST,  (9S  LOOPHI 

17901 

OP  20  SUP1 *0E ST,  2PUSH  LOOPHI 

1S971 

COR  20  SUB1«BEST,  LOOPHI 

SU32  •  SUB?  ♦  1 

7 

17*11 

SUB?  «  (PS  S'J32  ♦  1 

17971 

SUB?  •  2PUSH  SUB?  ♦  1 

17941 

SUB?  •  ABS  (SUB?  ♦  1) 

17941 

SUB2  •  2PUSH  (SU3?  ♦  1) 

t  •  NE"3PT (SUB?) 

• 

17971 

1  «  PEN3RTU3S  SOS?) 

17991 

K  «  NEN3RY ( 2PUSH  SUB?) 

IE(R  .S3.  •»•)  ICR  •  4 

9 

10 

ISS41 

IMPENORMSUP?)  .EB.  •»•)  |CR  ■  4 

•  •001 

IM43S  C  .13.  •§•)  IER  p  4 

•  S071 

1 E ( 2 push  r  .EO.  '»•)  ICR  •  1 

10 

PEPORT(SUBI)  ■  r 

11 

1SS91 

PE*0RY(SUB1)  •  NE"3RT(SUB2> 

18331 

Pt«ORT((BS  SUB1)  «  R 

•  8351 

P»P0RT(2PUS«  S'JNT)  «  r 

18381 

P£«ORY ( SUB1 )  •  2 RUSH  t 

IMIER  ,NE.  3)  SOTO  9*98 

1? 

13 

17(31 

I  E  ( I  E “  .GT.  3)  SOTO  9999 

1*7*1 

I r « I c *  .NC.  3)  BETURN 

Figure  4  MOVENW  and  MOVENM  Listings  With  Equivalent 
Mutants  and  Mutant  State  Information 
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IMPtf"  .Lf.  “LEW)  SP1f>  9999  1*  15 

*25*1  IMDLEv  ,L£.  SLEW)  ton  9999 
*7*91  I(<0U5  .fS.  MLEM)  6010  0999 

**0’*  IKA3S  PlfM  .If.  Ml  TV)  SOTO  9999 
*(11*  IM1*US1  Olfv  .It.  MIEN)  «MP  9999 
**19*  IftBirn  .LC.  AMS  «1|.E N>  S010  9999 
i>m  if  (on  *  .c.  i»usm  turn  tots  9990 
**?•*  if  col t  s  .le.  Mirm  return 

■  I  *  LPOPrl  ♦  1  it 

**15*  t  *  MS  LOC»MI  ♦  1 

*»m  i  *  z»ush  iso°hi  ♦  1 

*«1?*  I  •  APS  (LOOPMI  ♦  19 

**23*  1  «  e»usm  ttooPHj  ♦  i) 

LSSMI  •  <0f ST  ♦  0LEN9  -  1  IT 

*s2ii  lOSP^T^rTMTTTTT^TnTP^-  1 

*523*  LOOPMI  •  (2PUSM  Of  S T  ♦  OlfNI  -  1 
*S2A*  LOOPMI  •  (0t$T  ♦  A»S  #(. EN)  -  1 
SS2S*  LSJOHI  *  (OtST  ♦  EPUSM  OLEN)  -  1 
**??»  LOSPMl  •  MS  (OtST  ♦  OLEN)  -  1 
1*29$  LOSPHI  *  2°USH  (OtST  ♦  OLEN)  -  1 
»<!S3t  LOOPMI  *  MS  ((OtST  ♦  PLEN)  *  1> 

S 332*  LOSPHI  «  EPUSM  ((OtST  ♦  OLEN)  -  1) 

OS  S3  SUP1*I,  LOOPil  1* 

*633*  PS  33  SUPl = A  3  S  1.  LOOPMI 

**35*  OS  33  SUBW»US«  J,  L03»H1 

*£3Sl  OS  33  SUS1=I,  ASS  LOOPMI 

**3S»  OS  33  S031«I,  2PUSM  LOOPMI 

*591*  00  9999  SU91M.  LSOPHI 

1*93*  TOP  30  SUB1«J,  LOOPMI 

33  REPORT (SU91 )  «  •  •  19 

*•39*  Pf»0R1(A9S  SU31)  «  »  • 

»«*1*  MfMORrdPUSH  SUB1 1  •  •  • 

9999  CONTINUE  20 

**S3*  RETURN 

RETURN  21 

TVO 

MUTANT  STPTE  fOR  MDVENW 

fOR  E**CRIMENT  "NOWENW  *  THIS  IS  RUN  T 
MU»PER  Of  TtST  CASES  •  11 


NUMBER  Of  OUTPUTS  ■  193 

NUMBER  Of  Of AO  MUTANTS  ■  *21  (  91. PI) 

NUMBER  Of  UVf  MUTANTS  ■  0  (  0.0*) 

NUMBER  Of  E9UIV  MUTANTS  ■  72  (  1.1*9 


number  or  mutants  which  one  »t  non  stanoarp  pears  sis 

NSRMALltEP  MUTANT  RATIO  821.0* 

NUMBER  Of  NUT AT ABLE  STATEMENTS  »  21 

CIPINC  A  MUTANTS /STATE PENT  RATIO  Of  A2.S2 

MUMPER  Of  DATA  REfERENCES  •  «E 
N'JMfiER  Of  UNI  SUE  0A1A  REfERENCES  •  U 


RLL  MUTRNT  TYPES  NAPE  IEEN  ENAILEO 

Figure  it  cont. 
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LISTIV 


446504 

446524 

446534 

446554 

446561 

446534 

446594 

446614 


446621 

446644 

446664 

446674 

446664 

446704 

446714 

446754 


446744 

446764 


445454 

446774 

446794 


446534 

446524 


446534 

446354 

446364 

446394 


446924 

446944 

446954 

446954 


447314 

447334 

447344 

447074 

447094 


447104 

447124 

447134 

447164 

447154 


3  H(  yvlT  “•OVCII  UJf*  S*(CI4|0  fJJJV  "UIANES 


SU1 ROUTINE  NO VENlCSOUFCE, SLEN. SOEC, PEST, DLfN,D0EC,T»P=:) 
L011CU  NE'-NO 


IXtFGE* 

*<<>,  PT*fGD, 

ptnegs,  k0 

S  U  3  2  , 

SUM 

,  L01»“I, 

HTf  si* 

LESS,  I, 

HI, 

DDECFT,  SDECPT, 

IER. 

ST»!(3,13) 

1 VT  F  g r  fc 

CC^EESD), 

SY* 

TA9(1L',9) 

CHIP  < 

IPPY(4?5> 

INTEGER 

T YDDE ,  OOEC# 

DLCN,  OEST, 

SOEC, 

SLEN 

,  SOJRtr 

1n»ut  output  ier,  “ENORy 

mux  ttppc ,  ooec,  oien,  pest,  soec,  slen,  source 

PTNESS  •  (SOURCE  ♦  SlfV)  -  1  23 

RTNEGS  «  (AIS  SOURCE  ♦  SLEN)  -  1 

•mis  *  (ZEjSH  SOURCE  ♦  SLEN)  -  1 

PTNEGS  «  (SOURCE  ♦  ASS  SLfN)  *  1 

PTNESS  •  (SOURCE  ♦  2RUSX  SLEN)  “  1 

PTNEGS  *  A9S  (SOURCE  ♦  SLfN)  -  1 

•HESS  •  2PJS“  (SOURCE  ♦  SLED  -  1 

•TNEGS  *  49  S  {(SOURCF  ♦  SLFN)  -  1) 

PTNEGS  •  2P‘JSP  ((SOURCE  ♦  SLE«>  '  1> 

PTNE  GO  «  (DEST  ♦  DLCN)  *  1  24 

°TN£GP  »  C A 3 S  PEST  ♦  PLEN)  -  1 

PlNFSD  •  (2PUSS  OF  ST  ♦  DIES')  -  1 

PTNEGP  «  (DEST  ♦  A9S  DUES)  “  1 

PTNEGD  •  (DFST  ♦  ZPUSM  DLEN)  -  1 
PTNEGC  •  A3S  (OFST  ♦  DUO  *  1 

PTNEGP  •  2PUS-I  (BEST  ♦  OLEN)  -  1 

»TN£GD  •  695  ((BEST  *  DUES)  -  1) 

PTNF  GO  •  ZPUSH  ((BEST  ♦  DLEN)  -  1) 

CALL  UN»ACF(9£*0RTCPTPCGS).X,5)  25 

CALL  UNPAC<<<1E«0RY(APS  PTNESS), 4, 5) 

CALL  UNPAC3<NE«!CIRT(7PUSM  PTNIGS)»7,5> 

WE  190  •  »<2)  .13.  26 

NESNO  «  4(2)  .SE.  •“* 

SEGNO  •  A9S  4(2)  .EG. 

NESNO  •  2 PUSH  x(2)  .13. 

4(2)  •  •  • 

If(NESNO)  CALL  PACC <  4,P|N!)R  Y  (PTNEGS)  ,  5  > 

IE  (SEGNO)  CALL  PACK(4,SETJRr<49S  PTNEGS), 5) 

IE(SESSO)  C*LL  PACC<4,SES0RT(I»US1  »TNESS),S) 

LESS  «  SLE3  -  SOEC  33 

LENS  •  APS  SLEN  -  SOEC 
LENS  •  IPUSR  SLEN  -  SPEC 
LENS  «  SLEN  -  A3S  SBfC 

LENS  •  APS  (SLEN  -  (PEC)  _ 

LEND  •  5LEN  •  60EC  11 

LESS  ■  ACS  CLEW  -  CMC 
LEND  •  {PUSH  OLEN  -  DDEC 
LEND  •  OLEN  -  A3S  OOEC 
LEND  •  APS  (DLCN  -  OOEC) 

SOECM  •  SOURCE  ♦  LENS  32 

SOSCM  •  AOS  SOURCE  ♦  LENS 
SOIC»T  •  IPUSN  SOURCE  ♦  LINS 
SOECM  >  SOURCE  ♦  AOS  LENS 
SDECPT  >  ASS  (SOURCE  ♦  LINS) 

SOECPT  ■  1PUSH  (SOURCE  ♦  LENS) 

OOECM  ■  DEST  ♦  LENO  33 

OOCCM  ■  AOS  OEST  ♦  LENO 
OOEC»T  •  2PUSN  OEST  «  LENO 
OOECM  •  OEST  *  AIS  LEND 
ODfCPT  •  ItS  (OEST  ♦  LENO) 

OOECM  ■  {RUSH  (OEST  *  LENO) 


27 

25  29 


Figure  4  cont 


53 


su?i  ■  tofc®t  -  i  u 

1*7194  SU31  .  t )<■  POffM  -  1 
1*7214  SL'81  »  IPUSH  OOEf»T  -  1 

4*7224  SUSl  •  *»S  (rjfCpT  -  1) 

4 472*1  SUSl  •  IPUSH  ( OPE  cp 1  -  1) 

1MS0EC  .63.  P  .as.  ope:  •  E 3 .  D)  GOTO  22  15  j4 

4*553*  IMSOEC  .IE.  3  .04.  POEC  .1 9.  0)  GOTO  22 

*45574  ir (safe  .£S.  a  ,os.  tore  .le.  0)  cpto  ?2 

I  HI  •  (SOEC  ♦  SOEC®!)  -  1  v 

4*7251  INI  ■  <*PS  SDIC  ♦  SPEC®!)  •  t 

4*7271  IHI  «  OP'JSH  SPEC  ♦  SPfC°T>  -  1 

1*7251  INI  «  (SOEC  ♦  ASS  SPEC’!)  -  1 

4*7534  1  HI  «  (SPEC  ♦  IPUSH  SPEC®!)  -  1 

4*7511  XHl  «  A»S  (SPEC  *  SPEC®!)  -  1 

4*733*  I  HI  «  IPUSH  (SPEC  ♦  SPEC®!)  -  1 

1*73*1  IHI  >  APS  ((SPEC  ♦  SPEC»T)  -  1) 

4*734*  I H I  «  IpUSH  ((SPEC  ♦  SOECPT)  -  1) 

IE (OPEC  .LE.  SOEC)  IHI  *  (OPEC  ♦  SDECPT)  -1  34  39 

4*3334  !((♦<  OPEC  .LE.  SPEC)  IHI  *  (POEC  ♦  S0ECP1 >  -  1 

*45531  I F (DOE C  .LT.  SPEC)  1*1  •  (OPEC  ♦  S8EC»T>  -  1 
4*7371  IF(A3S  POEC  .IE.  SOEC)  IHI  ■  (OPEC  ♦  SPEC®!)  -  1 

4*7391  IFdPUSH  OPEC  .LE.  SPEC)  IHI  *  (OPEC  ♦  SP>C»!)  -  1 

**7*.hi  impoec  .le.  ass  spfC)  Ihi  •  (pore  ♦  sore®!)  -  i 

4*7*21  IMPOEC  .LE.  IPUSH  SOEC)  IHI  ■  (OPEC  ♦  SPEC*!)  -  1 

«A7i3t  II (POEC  .LE.  SOEC)  IHI  »  (AE$  POEC  *  SOEC®!)  -  1  _ 

4*7*51  I E (POEC  .11.  SPEC)  IHI  •  (IPUSH  OPEC  *  SPEC®!)  -  1 

4*7*51  IMPOEC  .LE.  SOEC)  IHI  •  (OPEC  ♦  A3S  SPEC®!)  -  I 

1*7*31  IMOOEC  .LE.  SOEC)  IHI  *  (OOEC  ♦  IPUSH  SPEC®!)  -  1 

**  HOPE* 


00  23  SUS2-S0EC®!,  IHI 

1*7551  TO  23  SU92M3S  SPEC*!,  IHI 
1*7521  OP  20  SUH?*I®USH  SPEC®!,  IHI 
1*7551  no  23  SUP2*SDEC»T,  APS  IHI 
147531  DO  23  SUS2*SDEC®T,  IPU5H  IHI 
153921  I  OR  23  SUP2-S0ECPI,  1HJ 

S'J31  «  SUSl  ♦  1 

4*7611  SU31  *  ASS  SU®1  *  1 
1*7631  SUSl  «  IP'JSM  SUSl  ♦  1 
1*76*1  SUSl  «  APS  ( SUSl  ♦  1) 

4AT6SS  SUSl  »  IPUSH  (SUSl  ♦  1) 

C  -  HEHOSMSUJ?) 


1*7571 

r  «  Nf ®OPT (AES 

SUB2) 

1*7671 

r  •  NE NOS! (IPUSH  SUS2) 

IM<  .EO.  •»•) 

IER  ■ 

4 

*22*2 1 

IMS  .EO.  •#•> 

IE#  » 

OLEN 

*22**1 

ucr  .es.  •»') 

IER  • 

LENS 

*22*51 

IMS  .ES.  •*•) 

IER  » 

SPEC 

*22*7* 

IMS  .ES.  •»') 

IER  • 

POEC 

43*571 

If (NEP0SY(SUP2)  .ES. 

•id 

4*7701 

If (ASS  r  .ES. 

•»•)  IER  >  , 

4*7724 

!F<I»USH  C  .ES 

.  •••> 

If*  ' 

13  NEN0RMSUS1 )  •  « 


43A®*1  PEHOST(SUSl)  «  NEH0RYCSU82) 
1*7734  «l NORM  APS  SUSl)  •  t 
l*77Jf  N(NOST(IP)$M  SUSl)  ■  * 
4*776*  PESOS! (SUSl I  ■  ASS  « 

4A77J1  NfN0«T(SUP1>  •  IPUSH  * 

IFIISS  .1*1.  3>  SOTO  SO 

4*5111  IMIES  .*!.  0)  S0!0  $0 
*5026*  IMIES  .Nf.  0)  SOTO  AO 


*3 


*1 


*2 


*3  ** 


*5 


*6  A7 


Figure  4  cont 
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22 

311961 1  .43.  5030  *010  SC 

*• 

S9 

1 

SS77  9* 

HUBS  BBfC  .If.  3030  4010  34 

1 

»S?S2* 

JHODft  ,L£,  43S  5030  SOTO  30 

s 

1  •  SUS1  ♦  1 

SO 

1 

U79SI 

]  •  BBS  SI* 31  ♦  1 

1 

J  *  laJSW  VJM  ♦  ^ 

1 

ftft753f 

I  ■  495  (SOU  ♦  1) 

ft 

*S790* 

I  *  2*U Sn  (SU?1  ♦  1) 

1 

HI  «  <03 ST  ♦  04FN)  -  1 

51 

1 

*S791* 

III  •  dpi  Of  ST  ♦  04  3  4)  -  1 

1 

*4793* 

HI  *  (?*JS«  03  ST  ♦  04  3  4)  -  1 

1 

*4794* 

III  *  (BEST  4  43S  043 N)  -  1 

M 

*4794* 

HI  *  < DC  ST  4  2*US4  043*’)  -  1 

■ 

*4797* 

III  *  IBS  (BEST  «  0434)  -  1 

1 

*4799* 

HI  •  1PU54  (03 ST  4  0L34)  «  1 

I 

S  14833* 

14 1  •  4BS  < (03  S t  4  0434)  -  1) 

| 

!  *4*32* 

HI  *  1*054  ((03ST  4  0434)  -  1) 

1 

[■ 

DO  23  SOPH),  Id! 

52 

1 

t  *1148* 

00  25  SU3H1,  9143  6 0 

1 

*4*35* 

OP  25  SU41«*3S  I,  INI 

i 

ift*C5ft 

OP  25  SUeWJSH  1,  IHt 

1 

»4Sr.Af 

or  25  supi»i.  *as  im 

1 

F  *483*1 

00  25  SUSHI,  I»US4  HI 

1 

i  *3373* 

OP  53  SU4H1,  1HJ 

1 

*  5093* 

3PR  25  $(1*1*1,  HI 

1 

25 

43309KSU81)  «  ‘O' 

53 

1 

*4339* 

4340BY (  •  3S  SU311  *  ,P‘ 

1 

*4311* 

43*9*)T(2PUS4  SUS1)  •  '3' 

N 

SO 

40P*4l  *  4340 

5* 

] 

*4312* 

499*41  *  *3S  4340 

I * (43 43  .43.  4340)  400*41  •  4C1S 

55 

56 

i 

i  *12*** 

IHIII'S  .L£.  400PMI)  LOPPNI  •  4  34S 

*4359* 

If<«4  4*4S  .43.  4340)  100P4J  •  4FVS 

< 

*4591* 

l 3 (43NS  .41.  4340)  400*41  •  L3NS 

14515* 

I 3 ( IBS  13' 5  .43.  4340)  400741  *  43*5 

*  UM«> 

)3( tt».S  .43.  MS  4340)  trO®4J  *  4F4S 

*4321* 

I3(t34S  .43.  4310)  (.PDP-11  »  *BS  4345 

i 

sun  «  cos ;°r 

57 

I  *4*24* 

SJ81  •  IBS  0033*1 

ft  US?tt 

S961  *  3PUS4  003  COT 

< 

1 

SU32  «  S03CP1 

55 

1  *4827* 

S  J*2  •  »BS  SDFC»T 

1  *4*29* 

S2P?  «  2PJS4  SOECPT 

I 

13(4340  .39.  0)  SOTO  50 

59 

63 

I  *2333* 

13(4340  .32.  !3»)  SOTO  53 

I  *4599* 

23(4340  .L{.  0)  SOfO  53 

1 

1M43NS  .30.  0)  SOTO  *1 

61 

62 

1  *1443* 

133400*41  .(9.  0)  SOTO  *1 

ft  (4604* 

13 (43NS  .43.  0>  SO 30  «1 

I 

00  *0  1*1,  490*41 

63 

1  11446* 

#0  SO  S0U«C3*1,  LQOPMt 

1  *1447* 

00  SO  S434.1,  400*41 

t  *1433* 

00  S3  0L34*1,  400*41 

ft  *1433* 

00  S3  S53C*1,  490*41 

|  31433* 

00  SO  00£C*1 /  400*41 

1  114M 

*9  SO  S0CCPH1,  400*41 

ft  *1437* 

09  S3  003C*T*1.  400*41 

ft  (1439* 

09  S3  14J»1,  499*41 

ft  *1441* 

OS  SO  HI,  400*41 

ft  11441* 

03  S3  400*41*1,  400*41 

■ 

L  i 

Figure  4  cont. 
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$*J9i  *  suet  •  i  6t 

*48336  S  JS1  «  AAS  SU31  -  1 

*4*3*1  sjai  ■  /p jsh  subi  -  i 
*4MM  s J3i  ■  »?:  (sun  -  i) 

»4f3*6  SJP1  ■  /PUSH  ( SU31  -  1) 

SUS2  a  $U“7  -  1  65 

548391  SJJ7  a  63 S  SU»7  -  1 
54*416  SJ92  •  IPJSH  SU92  •  1 
>42421  S JP?  a  635  ( S J3 2  -  1) 

648446  SJS2  •  /PUSH  ( SUB2  •  1) 

K  •  NEN08Y(SU82>  66 

<48456  <  ■  963581(4*5  SU32) 

648476  t  a  913031(2 PUSH  SUP2) 

IKK  .13.  •*•)  16*  •  4  ‘7  6? 

6367 j*  If <3635*Y<S032)  .fl.  •«•)  IfS  •  6 
14»4*6  IK4PS  t  .f8.  If»  a  4 

645506  1K/PUSM  5  .ta.  168  a  4 


43  963381(5031 >  *  (  69 

6  36*66  *f 3381 ( SU91 >  «  «f30«i(Sjg2) 

64*516  ** 933 1 ( APS  SU91)  «  r 

643531  *fc 3381 ( /PUSH  SU31 )  a  K 
*48566  3E3381 (SUBI )  •  /PUSH  5 

IKIE*  .96.  0)  SOTO  SO  70  71 

646236  I f ( 168  .ST.  P)  SOTO  50 
650536  J f ( 16°  .1'C.  P>  SOTS  20 

] f (LEND  .16.  LENS)  SOTO  SC  77  73 


617436  IKL6ND  .LE.  LOOPHI)  SDTO  50 
145576  If (A3S  IEV0  .16.  LENS)  SOTS  50 
645596  IK/PUSH  LEND  .LE.  Lf NS)  SPTO  50 
548401  I f (LEND  .LE.  A3S  LENS)  GOTO  50 
646426  I f (LEND  .LE.  /PUSH  LENS)  S3T0  $0 

41  IHI  •  SU31  -  1 

64*435  /HI  a  4BS  SUS1  -  1 
648456  HI  •  /®USH  SU81  -  1 
643465  IHI  a  ABS  (SU31  -  1) 

6484*5  /HI  a  /PUSH  (SUS1  -  1) 

03  45  I*OE ST .  IHI 

648696  00  45  I«A*S  DEST,  IHI 

645716  DO  45  Ja/PUSH  OESf,  IHI 
648726  DO  45  /aftEST,  ABS  IHI 
648746  DO  45  laOEST,  /PUSH  IHI 
650916  DO  50  l-DEST,  IHI 
650956  f 08  45  I»DEST,  IHI 

45  963031(1)  a  *0‘ 

64875*  3E338KA8S  I)  •  *0* 

*45776  3E908YOPUSH  I)  •  »0» 

50  *(?)  • 

1KNESH3)  CALL  *ACKU,9|N0«1(PTNESS>,5> 

648781  I f  (NESNO)  CALL  PACK(*,NCN0*1(6tS  PTNESS),5) 

648306  I f (NESNO)  CALL  PACK(*,N£30*1(|PUSN  PTNE6S),S) 

IK. NOT.  (NESN3  .AND.  TTPPE  .(>.  2>>  8ETU8N 

*4881*  IK. NOT.  (NCSN3  .AND.  AIS  TTPPf  .11.  2>>  8ETU33 
*4883*  IK. NOT.  (NESNO  .AND.  {PUSH  TT»PI  .19.  2))  3ETJ3N 

CALL  UNPACK(NEN0*1(PTNESD)#8#5) 


74 


75 


76 


77 

78  79 


FO  81 


82 


*578  CALL  UNPACK(3|33*1(PTNC«D>,*,4) 

82580*  CALL  UNPAC*(NfN0*1(PTN(S0>,(,tDEC> 
*2577*  CALL  UNPAI*CNEN0»1(PTN««0),*,T1PPl> 
•5015*  CALL  UNPACC(N{90*T(PTN((t>,8,3> 

*1018*  CALL  UNPAC<(3EN087(PTNtt8>,l,?> 

•  4884*  C4LL  UNPACK  (NENONKAtl  PT«(I»).6,5) 
**888*  CALL  UNPACK ( Nl NO* 1C/PUIN  PTN((D),6,S> 

.  109+  »*%«  *  r  •»  • 

Flgur*  4  cont. 


56 


125931  RCTTPPEX  •  *•' 

CALL  PACr(«#M£MpRT{»TNES0>.5>  ®4 

148571  CALL  PAC4<X,NEN0AY(A}S  MTNESDJ.5) 

145891  CALL  paCKCX,M€90RT<2PUSH  PTNEGD>,5> 

RETURN  85 

£00 


mutant  elimination  profile  for  novfnm 


MUTANT  TT®€ 

TOTAL 

DC  AD 

clVf 

C  2  u  I C 

constant  replacement 

64 

63 

9!  .4* 

3 

0.3* 

i 

1.43 

SCALAR  VARIABLE  RC°LAC£Mf 

1920 

1936 

99. SX 

3 

3.3X 

14 

P.73 

SCALAR  F OR  CONSTANT  RE®. 

63C 

672 

95. 7X 

3 

3.3X 

5 

1.3T 

CONSTANT  FOR  SCALAR  RE®. 

331 

331 

133. ax 

3 

3.3X 

3 

3.3- 

SOURCE  CONSTANT  REBLACEME 

102 

100 

9B.PY 

3 

0.3X 

2 

2.PX 

ARRAT  RET.  TOR  CONSTANT  R 

179 

179 

100.  OX 

3 

0.3X 

3 

3. IX 

ARRtr  REF.  FOR  SCALAR  RE® 

547 

543 

99. 3X 

3 

3.3X 

4 

0.71 

COMPARABLE  ARRAY  NAME  RE 

40 

40 

130. 3X 

3 

3.3X 

3 

o.oi 

CONSTANT  FO»  ARRAT  REF  RE 

40 

40 

IOC. OX 

3 

O.PX 

0 

0.  OX 

SCALAR  FOR  ARRAY  REF  R£P. 

315 

315 

1 30. 3X 

3 

n.  3x 

3 

0.3* 

ARRAY  REF.  F3R  ARRAY  REF. 

75 

75 

130. 3X 

3 

3. 3X 

3 

3.33 

UNARY  OPERATOR  INSERTION 

191 

159 

99.  OX 

3 

D.3X 

2 

1.33 

ARITHMETIC  OPERATOR  RfPLA 

107 

107 

IPO. OX 

3 

O.PX 

3 

0.P1 

RELA1IONAL  OPERATOR  repla 

9B 

B9 

9P.BX 

3 

0.3X 

9 

9.27 

LOGICAL  CONNECTOR  REPLACE 

13 

13 

133. OX 

3 

3.3X 

3 

3.33 

ABSOLUTE  VALUE  INSERTION 

243 

93 

IB.BX 

3 

3.3X 

147 

41.31 

statement  analysis 

29 

29 

1P3.0X 

3 

0.3X 

3 

0.01 

STATEMENT  DELETION 

35 

35 

133. OX 

3 

0.3X 

3 

3.’'* 

RETURN  STATEMENT  RE»LACCM 

61 

61 

133. OX 

3 

D.n 

3 

3.33 

GOTO  STATEMENT  RE°IACE"EN 

49 

47 

95. 9X 

3 

D.3X 

2 

4.13 

DO  STATEMENT  ENP  RE'LACEM 

32 

25 

75. IX 

3 

0.3X 

7 

21.  ix 

MUTANT  STATE  TOP  MOVENM 


TOP  !»®ERIMEN7  "MOVENM  "  THIS  IS  RUN  22 
NUMBER  Of  TEST  CASES  •  *1 


NUMBER  OF  MUTANTS  •  5095 

NUMBER  3f  OE A3  MUTANTS  »  4599  t  96.2X) 

NUMBER  BE  LIVE  MUTANTS  «  0  <  3.0!) 

NUMBER  OE  E9UIV  MUTANTS  »  196  (  3.5W 


NUMBER  OF  MUTANTS  WHICH  PIED  ST  NON  STANDARD  MEANS  2706 

NORMALIZED  MUTANT  RATIO 

NUMBER  Of  MUTATABLE  STATEMENTS  •  65 

GIVING  A  MUTANTS/STATEMENT  RrTlO  OF  80. 5? 

NUMBER  OE  OATR  REFERENCES  M  155 
NUMBER  Of  UNIRUE  OA1A  REFERENCES  «  52 


ALL  MUTANT  TIRES  NAVE  SEEN  ENABLED 


Figure  4  cont 
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t 


LISTING  t«  »•!  UNIT  "ROVIED 


5 


13 

11 


15 

IS 


23 


30 


SJ3R3JTINE  R3mO(SOU*C£,SL£N,SGf  C,PFST,DLFN,».:N,»OIG,*nEr, 
PIC, IER) 

LOGICAL  SUfRrS,  NEGNO 

INTEGER  1(51,  SU92,  SU31.  l*U,  PLDIG,  1VAK,  1,  SCOUNT,  OESt-tl 
INTEGER  CHAR,  P01CLN,  SDIG,  SAR*AY(S3),  P1CST,  09EC 
INTfSEP  $1*1(3,10),  COOE(SO>,  SYRTA?(10,9) 

CHAR  RE R0»Y(313> 

INTEGER  IER 
CHAR  PI C  < 1 3) 

INTEGER  POEC,  PDI G,  PLEN.  PLEN,  PE$1,  SPEC,  SLEN,  SOURCE 
lV’UT  0U1PU1  RENORT,  IER 

IN»UT  »IC,  PpEC,  PD1S,  »LEN,  PLEN,  PES1 ,  SPEC,  SIFV,  SCJPCI 
SU»»ES  *  .TRUE. 

PO  5  1*1,  ®LE  N 
SHHT(I)  *  'O' 

PLDIG  *  PPIG  -  PPEC 
SOIG  *  SLEN  -  SPEC 
Jf (SPEC  .EG.  0)  S010  11 
SUIT  »  PLPTG 

SU3?  «  (SOURCE  ♦  SDIG)  -  1 
DO  13  1*1,  SPEC 
SU11  «  Sl'EI  ♦  1 

SJ32  *  SUB 2  ♦  1 

IF(R£R9RY(SU37>  .ED.  ■••)  II*  »  4 
SARR  AT ( SU31  )  «  RE "JRYCS J92) 

IEdSR  ,N£.  0)  6019  101 

IF  (SDIG  .CE.  PLDIG)  IHI  *  PLPIG 

IF (SOI  5  .Li.  PLDIG)  INI  «  SDIG 

SU91  »  PLPIG  ♦  1 

S'J52  *  SOURCE  ♦  SDIG 

DO  IS  I«1,  IHI 

SJ31  *  SU91  *  1 

SUP?  *  Su«2  -  1 

I F (*E*0R1 ( SU32)  .EG.  •»')  If*  *  4 
SABRAT(SUei)  *  *t“0*1(SU9?> 

IF (IE*  .HE.  9)  S010  101 
SUP1  »  (SOURCE  ♦  SLE'i)  -  1 
CALL  UN»AC<(«E*0RT(SU»1>,*,2> 

REGNO  •  X (2)  .EG. 

SU91  *  PE  SI 
SCC'JNI  •  3 
PO  100  I«1,  PLEN 
SU31  «  DES1  ♦  I 

IF ( (DES1  ♦  I)  -  1  .ST.  (OLEN  ♦  PEST)  -  1>>  GOTO 
CHAR  »  PIC(I) 

IF(PICO)  .EG.  *»•>  3U»*ES  •  .FALSE. 

IF(SA**A1(SC0UH1  ♦  1)  .HE.  •O')  SUPRES  «  .FA-SE. 

IF(CHA*  .HE.  •-•)  SOTO  20 
RE*0*T(SUB1  -  1)  »  •  • 

I F  ( I  .EG.  1  .AND.  NEGNO)  RERORY(SUB)  -  1)  • 

I F ( I  .EG.  1)  GOTO  100 
SC3UNT  «  SCOUNT  ♦  1 
I F ( , NOT.  SUPRES)  GOTO  99 
IF  (NEGNO)  REPORT (SU91  -  1)  • 

I F  (REPORT ( SU91  -  2)  «EQ.  <-•)  RER0GYCSU91  ->)*•• 

GOT  0  103 

IF(CH*R  .Nr.  '♦')  SOTO  30 

I  f  ( I  .EG.  1  .ANO.  NEGNO)  RSR0RKSUA1  -  1)  • 

I F ( I  .EG.  1  .AND.  .NOT.  NEGNO)  RER0RYCSU91  -  1)  * 

I F ( I  .eg.  1)  GOTO  100 
SCOUNT  •  SCOUNT  *  1 
I F ( .NOT •  SUPRES)  SOTO  99 
ir  (NEGNO)  RER0RKSU91  -  1)  • 

IF  (.NOT.  NEGNO)  RER0*V(SUB1  -  1)  ■ 

IF (RERORT( SU31  -  2)  .EG.  •♦•>  PCR0*Y(SU91  -  2)  ■  •  • 

IF (RER0*Y(SU91  -  2)  .EG.  •-•)  R£R»»Y(SUS1  -  *)  «  •  t 
SOTO  133 

IF (CHAR  .NE.  •*')  GOTO  40 

IF  (I  .EG.  1)  REPORT ( SUIT  -  1)  •  ■!> 

IF (I  .EG.  11  GOTO  130 

SCOUNT  >  SCOUNT  ♦  1 

IF ( .NOT.  SURGES)  GOTO  9» 

RfN0RY(SUP1  *  1)  • 

IMPERORKSUBI  -  2)  .ft.  •«•)  RE*ORT (SUR1  .  2>  .  .  . 

*010  130 


F  7 


9" 

91 

5?  •>» 

Pt 
95 
94 

a? 

0< 

99  133 
11 
112  If! 

V  S 
1*7  If* 
1  9 
11C 
111 
11? 
Ill 
114  115 
1 1 ; 
117  11* 
11*> 
12? 
121 

172 

173 

174 

125 
126  127 
12' 
129  130 
131  137 
133  134 
135 
136  13? 
139  139 
140 
141  142 
143  144 
145  145 
14? 
145  149 

153  151 
152  153 

154  15? 
156 

157  156 
159  162 
161  16? 
163  164 
165  166 
167 
IF!  1*9 
170  171 
172  173 
174 
175  176 
177 
179  17? 
1*0 


I 

I 

j 


Figure  5  MQVEED  Original  Program  Listing 


( 


f 


.0 


IMC“AR  *•’)  S010  50  1-1  1  ? 

scount  «  scount  *i  vs 

IM.VDI.  SuPRCSI  SOTO  99  1*4  1E5 

PE*0RY(SU61  -  1)  «  1-* 

GOTO  100  1"’ 

a  IKCHIt  .NE.  GOTO  55  1  • ;  1'V 

SCOUNT  *  SCOUNT  ♦  1  1?j 

IK. NOT.  SUPRFS)  SOTO  99  1C1  1  ?2 

P£*ORY<SUB1  -  1)  »  •  *  I'-J 

GOTO  100  101 

5  1MCNAR  .HIE.  SOTO  43  14S  155 

SCOUNT  •  SCOUNT  ♦  1  19? 

«E»0RY(SU91  -  1)  *  SARRAYCSCOUNT)  1?t 

GOTO  103  1n- 

3  If<CN*e  .NF.  •  a •  I  SOTO  23  ?'3  2"1! 

PET0»Y(SUS1  -  1)  •  *  *  ?'? 

GOTO  103  ?"S 

3  IKCHAR  .NE.  •/•)  SOTO  8?  >  4  ??S 

PE»0*»(SU81  -  11  «  •/«  234 

GOTO  133  2  2 

0  T F  ( CNR 0  .NF.  *  W •  >  SOTO  gl  2':.  23? 

GOTO  130  21"> 

1  IMCN4R  .Nf.  •.•)  SOTO  12  211  212 

NE*ORT (SUB1  -  1)  »  •.*  212 

SOTO  133  214 

!2  IF  C CHRP  .NE.  *,*>  SOTO  *3  215  215 

I F  < . NOT •  SUPRES)  NEPOPTCSUOI  -  11  •  212  2 1  • 

IMSUPRFS)  PE-ORT  (SU91  -  1)  *  *  1  212  2?- 

SOTO  133  221 

03  IE9  *  3  222 

GOTO  101  223 

9  •IPORYCSUPI  -  1)  «  SARRAYCSC OUN T >  224 

33  CONTINUE  223 

31  CONTINUE  22* 

RETURN  227 

END 


Figure  5  cont. 


TEST  CASE  PURSER  9 

»ARt«ETrRS  ON  INPUT 

SOURCE  *  294 

SLFN  *  2 

SOEC  ■  7 

BEST  «  5 

OLE  N  *  8 

PIFN  «  t 

»6IG  «  7 
POEC  *  2 

PIC  »  "22229. 99»»" 

IFR  •  3 

REPORT  ■  -immUIIIIIIIHtlHIlHIIII  03101-  UJUUU 

•A  2222222222  35  13-  2352*2  ? 22? 

p.99  pppp.9  tltSSV  *»»*•»?. 99 

p  9,999.9  99299299  99999399  Mltmi 

•  lUIIKItlX  TTTTTTTTT3O43210233«ICPEELSr2IF2EtSC1  233  31  CONE  »»•»**»*«***• 

•*************#******f******UUUUUA22Z7Z22222  333533331 33 3-31 2545* 2** 


»*RI«CTF*S  ON  OUTPUT 

REPORT  •  "#f*»  123t.Si«l<l»)*TMMIIIII  33101-  UJUUU 

**  1122122222  35  ID-  235282  222? 

p.99  pppp.9  tlitlV  I*p***9.99 

•  9,999.9  99299299  99»*9«99  (IIITRIA 

PlllUIllim  TTTTTTTTTjr*321023P*»C0EILSF  21  F2EI.S21 23301 03PF  •*»•«* ******* 
•f«(******(****(«*(****»*(**UUUUU* 222222222 2  333533331333-312345*2** 


IE*  •  0 

Figure  6  MOVEED  Test  Case  that  Uncovered  an  Error 
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PIC  -  CHARACTER  array  which  contains  the  Cobol  PICTURE  for 
the  edited  move. 

INPUT/OUTPUT  DATA 

MEMORY  -  CHARACTER  data  that  contains  the  programs  memory. 

IER  -  INTEGER  used  as  error  indicator. 

The  numeric  edited  move  takes  data  from  a  source  field 
and  places  it  in  a  receiving  field  according  to  what  may  be 
called  a  template  or  instructions  specified  in  the  Cobol 
PICTURE. 

Through  the  course  of  mutation  analysis  two  errors  and 
redundant  conditional  statements  were  found  in  MOVEED.  The 
first  error  detected  involved  a  Fortran  DO  loop  where  the  DO 
loop  was  being  executed  once  when  it  should  not  be  executed 
at  all.  The  specific  statement  is: 

DO  15  1*1, IHI 

at  line  111  in  Figure  5  where  IHI  has  been  assigned  the 
value  of  SDIG  (number  of  digits  in  the  whole  part  of  a  num¬ 
ber)  or  PLDIG  (number  of  allowable  digits  in  the  whole  part 
of  the  PICTURE  description) .  The  test  data  that  uncovered 
this  error  is  shown  in  Figure  6. 

The  program  was  corrected  and  the  affected  lines  for 
the  new  program  are  shown  in  Figure  7.  The  new  line  is  the 
line  with  the  Fortran  statement  label  11. 

The  second  error  that  was  uncovered  by  mutation 
analysis  involved  the  handling  of  the  PICTURE  item  'V'  which 
means  that  a  decimal  point  is  not  placed  in  the  receiving 
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I F ( SOI G  .E9.  3  .OR.  ^LOIS  .EJ.  3)  SOTO  IS 

104 

105 

106 

I  HI  •  °L0  I  f. 

1C7 

10® 

IKSOIC  .LT.  PL  01  G)  1H!  «  SOIG 

i  ;? 

S'J  3 1  •  PLOIS  ♦  1 

1 1  D 

S'J32  *  SOURCE  *  SOIG 

111 

1)0  15  1*1.  IH1 

112 

S'JII  *  SU9 1  -  1 

113 

SJ32  *  SU92  -  1  . 

m 

115 

If < 3E30RY < SUB2)  .EG.  *»•>  IE*  *  * 

S  ARR  A Y (SU91 )  •  »E30RY(SU»2> 

116 

Figure  7  Corrected  Program  Section  of  MOVEED 


TEST  CASE  NJ»B£R  t 

SARA3ET£RS  om  input 


SCJRCE 

*  294 

SIE*  « 

s 

SDEC  » 

4 

^EST  = 

5 

OLEN  * 

7 

3L  E  N  * 

a 

PDIS  * 

7 

Pf>EC  - 

3 

PIC  « 

"9999V99?  " 

IER  • 

0 

*E 10R  f 

m  3i- 

UJJJU 

*4 

llllllllll  05 

13- 

235737 

7  7  Z  9 

•.99 

umv 

%  •**« 

>*9.99 

• 

9.399.9 

99799/93 

99399239 

XXXXXXXX 

•XXXXXXXXXIXI  YYYYYYYYY3r432132Dr’A9CDt£LSE2IF2£LSE12030103XEt»*#i'»**»cY** 

odosdoooi  3  on2S4  5 


P»RA*ETf9S  OV  OUTPUT 

•"E30RY  »  M*#t*1234567t*#####*#**t*#***t#  33131-  'JJJ'JJ 

•A  llllllllll  35  13-  235737  72Z3 


•  .97  ♦♦♦♦.9  IKSIY  t****#9. 99 

•  9,999.9  09/09/99  39999399  xxixxxxx 

•  IXXXXIXXXXXX  YYYYYYYYYir'  4321  r?3r*BCDtELSE21F2ELSE  12  O'*  D 1 1  ONE  •»»*«***>!»»« 

•#t*ftf«f**#ffi#ff#f*#tft#**UUUUUAZZZZZZZZZZ  33353333133>12345S7‘>«« 


IER  «  0 

THE  PR0GRA3  TOOK  1593  STf»S  TO  EXECUTE 


Figure  8  MOVEED  Test  Case  tli#t  Uncovered  Second  Error 
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field.  This  error  was  detected  from  the  data  shown  in 
Figure  8.  As  can  be  seen  from  the  program  in  Figure  5,  at 
statement  label  80,  if  a  V  is  the  item  in  the  picture,  then 
nothing  is  done  and  control  goes  back  to  the  top  of  the  loop 
where  the  next  item  in  the  PICTURE  description  is  retrieved. 
The  error  occurs  because  the  pointer  (variable  SUB1)  for  the 
next  available  location  in  the  receiving  field  is 
automatically  incremented  at  the  beginning  of  the  loop;  to 
correct  this  error  subtract  1  from  SUB1  when  a  V  instruction 
is  detected.  The  original  method  for  calculating  the  next 
available  location  used  the  DO  loop  index  and  the  absolute 
location  of  the  destination  field.  This  disregards  the 
statement  SUB1=SUB-1  executed  when  a  'V'  is  encountered, 
making  it  mandatory  to  rewrite  the  handling  of  the  destina¬ 
tion  pointer.  The  new  code  is  given  in  Figure  9.  It  has 
been  indicated  that  some  conditional  statements  were  redun¬ 
dant  in  the  original  program.  These  have  been  rewritten  as 
can  be  seen  in  Figure  9  also.  Figure  5  contains  the  program 
with  the  'V'  error  and  with  the  redundant  statements.  It 
can  be  seen  from  this  listing  that  several  redundant  con¬ 
ditional  statements  have  no  effect  on  the  result  of  the 
program.  These  redundant  statements  have  been  taken  out  or 
rewritten  as  can  be  seen  by  looking  at  Figure  9. 
Specifically,  a  redundant  conditional  statement  exists  for 
statement  106  where  IHI  is  assigned  the  value  of  PLDIG  if 
SDIG  is  greater  than  or  equal  to  PLDIG; 
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.£8.  0)  SOTO  16 


IF®  «  * 


listing  the  pros®*"  mu  “noveeo 

SUaR0'JTI NO VEE0<S0URCE,SLEN, SPEC, BEST, 6LEN.»LfN,»0lG. “DEC, 

m)!Ssu"r;NsuM,  IHI.  5f5T<J 

INTEGER  (HAR,  »0IGLN,  SDIG,  ->»  PlfST,  »>EC 

INTEGER  STYT(3,10),  CCDK30),  SY*TAN(ir,9) 

CHAR  HE  NOR  T  (31  3) 

INTEGER  IE® 

1MTESERCP0EC,  ®01G,  PLEN,  OLEN,  BEST,  SBEC,  SLEN,  SOURCE 
IN»UI  OUTPUT  HENDRY,  IER 

1H»U1  PIC,  POEC,  P0I6.  PLEN.  OLEN,  BEST,  SPEC,  S.EH,  S5JRC. 
SJPRFS  ■  .TRUE. 

DO  5  1*1,  PLEN 
5  SARRAT(I)  *  *3* 

PLCIG  *  PDIG  ‘  PDEC 
SOTS  *  SLE*!  -  SBEC 
IfCSBEC  .EO.  tl>  SOTO  11 
SU51  *  PLOIS 

S J?2  *  (SOURCE  ♦  SDIG)  -  1 
DO  10  1*1,  SBEC 
SU31  *  SU9 1  ♦  1 

SJ32  *  SUH?  ♦  1  , 

IF(NEHORr(SU92)  .EO.  IER  *  * 

10  SAFRAT (SUB1 I  *  PE«3RY<SU32) 

IMIER  ,KE .  0)  C3T0  1P1 

11  IF(S013  .EO.  0  .OR.  PLOIS 

IHI  *  PLPIS  ,  . 

IKSBIC  .LT.  PLOIS)  IHI  *  SDIG 
SUR1  *  PLOT  G  ♦  1 
SU»2  *  SOURCE  ♦  SO  I G 
00  15  1*1,  IHI 
SU31  ■  SUB  1  -  1 
SUH2  *  SUB2  -  1 
IF (NEHORYlSUS?)  . E8 .  ••') 

15  SARRAY(SUHl)  •  HEHORY ( SU52) 

IF (IER  . Nf .  0)  GOTO  1P1 

16  SU31  *  (SOURCE  ♦  SLfN)  -  1 

CALL  UNPACKNENORTf  SUM>,«,2> 

NEGNO  *  X(2>  ,E8. 

SU31  *  BEST 
SCOUNT  *  0 
00  103  1*1.  PLEN 
SU31  •  SUP  1  ♦  1 

I F ( SU31  .ST.  OLEN  ♦  BEST)  SOTO  101 
CHAR  -  PIC(I) 

IF(»IC(I)  .E8.  '9')  SUPRES 
IF(SARR«Y(SCCUNT  ♦  1)  .NE. 

I F ( CH AH  .NE .  •-•)  GOTO  23 
*E*08Y(SU«1  -  1)  »  '  * 
lF(NESNO)  Ht*0RY(SUS1  -  1)  *  ' 

1(11  .EO.  1)  GOTO  103 
SCOUNT  *  SCOUNT  ♦  1 
I F ( . NOT .  SUPRES)  GOTO  09 
IF(HENPRY(SUS1  -  2)  . E a .  '*')  penorycsubi 
goto  iro 
23  I F ( C H A R  .NE.  '♦'I  GOTO  33 

If(NEGNO)  HE*0»T(SUB1  -  1)  *  '** 

If(.NOT.  NEGNO)  «E»ORT(SUBl  *  1>  ■  *♦' 

1 F ( I  .EQ.  1)  GOTO  100 
SCOUNT  •  SCOUNT  ♦  1 
IK. NOT.  SUPRES)  GOTO  99 

l f (»f nORT(?U11  -  2)  .E3.  •♦•)  *E*0RT(SUB1  -  2>  p  •  • 

I F < *E NOR Y(SU51  -  2)  .Ea.  HENDRY (SUB1  -  2)  ■  •  • 

GOTO  133 

JO  If (CHAR  .ME.  **•>  SOTO  *0 
•EY0RYCSU81  -  1>  • 

IF (1  .Fa.  1)  S0T0.10D 
SCOUNT  •  SCOUNT  ♦  1 
I F ( . NOT •  SUPRES)  SOTO  99 

IF ( Nf H1RY(SUJ1  -  2)  .P8.  NEP0RY(SUB1  -  2)  »  •  ' 

sin  i no 

43  IFF  CHAR  .NE .  •••)  SOTO  50 
SCOUNT  *  SCOUNT  ♦  1 
fF(.NOT.  SUPRES)  SOTO  99 
'E"ory(subi  -  i)  ■  ••• 

GOTO  1C3 

53  I F ( CHAR  .HE.  SOTO  55 

SCOUNT  «  SCOUNT  ♦  1 

Figure  9  MOVEED  Final  Corrected  Program  Listing 
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I F ( . NOT .  SJBRES)  GOTO  09 

151 

1*4 

*£«ORY<SU31  -  1)  •  •  • 

155 

GOTO  TOO 

156 

55 

TFCCHAP  .Nf.  •»•)  GOTO  63 

1 1 7 

1‘P. 

SC3URT  •  SCOUR!  »  1 

159 

R!*ORT<SUJ1  -  1)  •  S»»«AT(SC3URT) 

193 

G3T0  133 

1«1 

*>3 

IMMAR  .NE.  >}•)  SOTO  73 

1  ®2 

1  FI 

"conis'j?'  -  i>  *  •  • 

194 

o  01 0  133 

195 

IFICRAP  .Rf.  •/•)  SOTO  S3 

176 

197 

*E»3*Y(SU“1  -  1)  •  ■/• 

19“. 

SOTO  133 

1  79 

'0 

IF (CRAP  .RE.  *  R 1 )  SOTO  51 

733 

201 

sum  »  sum  -  i 

232 

SOTO  133 

233 

’1 

IF (CHAR  .Nf.  •.<)  GOTO  57 

7'4 

235 

«E«0*T(SU61  -  1)  * 

206 

GOTO  I^O 

217 

•  ) 

IF (CHAT  .RE.  ',')  SOTO  55 

>G5 

239 

IFC.ROT.  SUFRFS)  MfRORTtSUBI  •  t)  »  *,• 

71.0 

211 

IF<SU>«ES)  *ER0*T<SU81  *  1)  •  •  * 

212 

213 

SOTO  110 

214 

’  1 

IE»  *  * 

215 

GOTO  1"1 

216 

•-? 

••E'ORTfSl'PI  -  1)  «  SARRATTSCOUNT) 

217 

t’3 

ClRTIRUE 

213 

1  ?  1 

0;  T'JRR 

219 

EVO 

Figure  9  cont. 


«lt.lT*ST  SEMINATION  PROFILE  FOR  ROVEED 


RHTART  TY’E 

total 

DEAD 

.lVf 

?  OUI  1 

CONSTANT  REPLACEMENT 

151 

144 

96.71 

3 

0.31 

5 

3.3* 

SCALAP  WA5IAPLF  Rf'LACE'E 

2450 

2413 

99.3* 

3 

0.31 

1  7 

0  a  77 

SCALAR  TOP  CONSTANT  RE 3 . 

1171 

111® 

99. R1 

7 

0.31 

2 

n .  2  ■' 

constant  for  scalar  re». 

594 

697 

99.7* 

3 

3.31 

? 

3.3'- 

SOURCE  CONSTANT  RE'LACE'E 

631 

599 

99.71 

3 

3.3* 

2 

0.3 

array  RET.  FOR  CONSTANT  R 

470 

470 

133. 0» 

3 

0*  jX 

3 

n.r* 

AFRAr  REF.  FOP  SCALAR  »EP 

1341 

1339 

9**91 

3 

3.3X 

11 

1*1* 

CO'PAPAPLE  array  narf  re 

14* 

145 

133.31 

3 

3.3X 

3 

0  •  V- 

constant  for  array  ref  re 

135 

105 

133.31 

7 

3  •  0  X 

0 

3.0* 

SCALAR  FOP  APPAY  PEF  PEP. 

514 

6*0 

99.47 

7 

D."X 

4 

APSAY  REF.  FOR  ARRAY  RIF. 

751 

246 

95.31 

7 

3. OX 

5 

2  •  0  x 

UNAPY  OPERATOR  INSERTION 

575 

513 

97.51 

7 

3.0* 

7 

2  m2'. 

ARITHMETIC  O'ERATIP  REPLA 

21* 

21? 

130.31 

7 

3  •  OX 

3 

3  . 

RELATIONAL  OPERATOR  REPLA 

210 

191 

91.01 

7 

3.  OX 

1  ? 

9.3- 

LOGICAL  CONNECTOR  REPLACE 

5 

5 

130.31 

7 

3  ■  j  X 

0.3* 

A3S0L JTE  VALUE  INSERTION 

399 

151 

37.51 

7 

3. OX 

?  45 

*2.2V 

STATf'EM  ANALYSIS 

53 

•  0 

130.31 

7 

3.  OX 

0 

3.0' 

STATE*ENT  DELETION 

56 

56 

100.31 

7 

3. OX 

3 

0.3* 

RETURN  STATEMENT  REPLACER 

12* 

126 

100.01 

3 

3. OX 

3 

C.ov 

GOTO  STATEMENT  REPLACEREN 

54P 

656 

9*. 11 

3 

3. or 

12 

1 .7* 

DO  STATERENT  end  peplacem 

76 

72 

94.71 

3 

0.  ox 

4 

5-3* 

•UTANT  STATE  for  movfed 
FOP  E*»ER!RENT  ”R3VEED  "  THIS  IS  RUN  IS 

NUR9E*  of  TEST  CASES  «  65 


ruts F*  OF  RUTANTS  *  9*41 

NUR®E*  OF  DE4D  RUT4NTS  ■  95 C 5  <  96. St) 

NU1PER  OF  LIVE  MUTANTS  *  0  <  0.01) 

RL)P»ER  of  E9UIV  MUTANTS  ■  331  <  3. At) 


RUR9EP  OF  MUTANTS  WHICH  DIED  ST  NON  STAROARO  'EARS  4539 

NORMALIZED  mutant  RATIO  •••••t 

RURSER  OF  RUTaTaSLE  STATEMENTS  ■  133 

SIVIRS  A  RUTAHTS/STATCRENT  RATIO  OF  73. *9 

NURSER  OF  DATA  REFERENCES  •  272 

nurse*  of  uni  sue  data  REFERENCES  ■  34 


ALL  MUTANT  TIMES  NAVE  SEEN  ENASLEO 

Figure  10  MOVEED  Status  Information  after  Testing 
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IF  (SDIG  .GE.  PLDIG )  IHI=PLDIG 
but,  the  next  statement 

IF  (SDIG  .LT.  PLDIG)  IHI=SDIG 

will  reassign  the  value  of  IHI  to  SDIG  if  SDIG  is  less  than 
PLDIG;  it  can  be  seen  that  the  first  conditional  statement 
can  be  changed  to  the  assignment  statement  IHI=PLDIG  because 
it  will  be  reassigned  if  the  following  conditional  statement 
is  true. 

Another  redundant  conditional  statement  is  the 

statement  containing  mutants  136  137  where  the  statement: 

IF  (I  .EQ.  1  .AND.  NEGNO)  MEMORY (SUB1  -  1)  = 
does  not  need  the  compound  conditional  portion  I  .EQ.  1 
because  the  next  statement  takes  care  of  that  portion  of  the 
conditional.  This  is  rewritten: 

IF  (NEGNO)  MEM  ORY  (S  UB 1  -  1)  = 

which  allows  the  deletion  of  this  statement  later  at  loca¬ 
tion  143  144. 

As  in  the  previous  conditional  statement,  envolved  with 
the  execution  of  a  negative  picture  item,  the  same  redundant 
conditionals  exist  for  the  positive  picture  item. 

The  code  for  dealing  with  the  Cobol  floating  dollar 
sign  can  be  compacted  for  the  same  reason  the  conditionals 
can  be  rewritten  in  the  code  for  the  floating  negative  and 
positive  signs. 

The  rewritten  MOVEED  subroutine  is  shown  in  Figure  9 
and  the  results  of  the  mutation  testing  indicate  that  the 


routine  is  now  correct.  Figure  10  contains  the  status  in¬ 
formation  for  the  testing  of  subroutine  MOVEED. 

After  becoming  familiar  with  the  FMS.2  system  the  test¬ 
ing  sessions  were  easier  to  conduct.  During  the  testing,  an 
error  was  detected  in  the  FMS.2  system  which  involved  COMMON 
blocks  where  the  data  items  had  to  be  defined  after  the  COM¬ 
MON  block  statement  which  is  oppositite  of  the  way  it  should 
be  with  the  declarations  before  the  COMMON  block  definition. 
As  an  inexperienced  user  of  the  FMS.2  system,  I  had  a  few 
suggestions  for  the  format  of  some  user  instructions  which 
were  mainly  personal  preferences  that  would  not  affect  the 
systems  performance.  I  also  gained  some  insight  for  user 
interface  for  the  CMS.l  system. 

I  found  with  testing  that  my  programming  style  could  be 
changed  in  order  to  avoid  redundant  code  and  unnecessary 
variables . 

The  results  of  the  routines  which  were  tested  revealed 
what  was  believed  to  be  true.  The  routines  MOVENM  and 
MOVENW  proved  to  be  correct  and  fully  tested.  The  testing 
of  subroutine  MOVEED  was  done  because  it  was  known  that  it 
had  not  been  fully  tested  and  might  contain  some  errors. 
The  testing  revealed  two  errors  and  allowed  for  the  complete 
testing  and  generation  of  sufficient  test  data.  The  three 
routines  are  now  tested  and  presumably  correct;  as  a  result 
of  the  testing,  I  have  confidence  that  the  routines  perform 
as  they  should. 


CHAPTER  IV 


CONC  LUS  ION 

Mutation  systems  have  been  implemented  for  Fortran, 
Lisp,  and  now  for  Cobol.  Mutation  analysis  allows  a 
programmer  to  improve  his  test  data  through  an  interactive 
process  with  a  mutation  system.  Performing  this  iterative 
process  allows  a  user  to  become  confident  that  his  program 
is  correct. 

CMS . 1  has  been  implemented  and  operational  since  the 
Fall  of  1979  with  no  reported  problems.  Several  of  the 
major  routines  of  CMS.l  have  been  tested  on  the  Fortran 
mutation  system,  FMS.2,  at  Yale  University  which  increases 
the  confidence  in  the  Cobol  system  as  a  useful  operational 
system  for  program  testing  of  Cobol. 

CMS.l  has  been  limited  to  a  certain  Cobol  subset  which 
should  be  expanded  to  support  a  wider  range  of  typical  Cobol 
programs.  These  expansions  should  include  Cobol  subroutine 
calls,  search  capabilities,  and  report  generation.  The 
system  was  designed  with  portability  as  a  major  considera¬ 
tion  and  also  with  expandability  of  the  system  in  mind.  A 
discussion  of  system  routines  and  machine  dependencies  is 
given  in  Appendix  B. 

A  current  limitation  in  CMS.l  is  the  I/O  because  the 
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input  and  output  must  be  in  buffered  core  arrays;  this 
problem  could  be  eliminated  by  redesigning  the  I/O  handling 
routines  to  use  disk  direct  access.  This  will  cause  some 
consideration  of  'What  is  meant  by  correctness  of  output 
with  direct  access  files'.  Will  it  be  required  that  records 
must  be  read  and  written  in  the  same  order  as  they  were  in 
the  original  program  or  should  the  final  results  be  the  same 
as  the  original  programs  final  results  without  caring  in 
what  order  the  data  was  generated.  If  the  requirement  for 
correctness  is  the  final  results  must  be  identical,  then  the 
mutant  programs  will  have  to  run  to  completion  before  a  com¬ 
parison  of  the  output  can  be  made;  this  will  slow  down 
processing . 

There  are  some  Cobol  data  types  which  are  not  currently 
implemented  in  CMS.l.  These  data  types  include  condition 
names,  alphabetic  type,  edited  alphanumeric,  computational 
type,  and  index  type. 

It  has  been  suggested  that  mutation  systems  might  be 
more  efficient  if  they  could  mutate  compiled  code  instead  of 
interpreting  code.  This  enhancement  would  require  the 
capability  to  decipher  compiled  code  to  determine  a 
statements  operation  and  the  capability  to  alter  this  code. 
Mutating  compiled  code  would  allow  for  easier  implementation 
of  subroutine  calls  and  the  necessity  for  a  SYMBOL  TABLE 
would  not  be  necessary.  The  mutation  of  compiled  code  would 
increase  the  efficiency  and  testing  time  of  programs. 
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